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Foreword 



This Technical Specification (TS) has been produced by the 3 rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, 
etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the Radio Link Control protocol for the UE-UTRAN radio interface. 
Features for the current Release: 
- Transparent mode. 

Unacknowledged mode. 

Acknowledged mode. 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are.either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 



[1] 


3GPP TS 25.401: 


"UTRAN Overall Description". 


[2] 


3GPP TR 25.990: 


"Vocabulary for the UTRAN". 


[3] 


3GPP TS 25.301: 


"Radio Interface Protocol Architecture". 


[4] 


3GPP TS 25.302: 


"Services Provided by the Physical Layer". 


[5] 


3GPP TS 25.303: 


"Interlayer Procedures in Connected Mode". 


[6] 


3GPP TS 25.304: 


"UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected 


Mode". 




[7] 


3GPP TS 25.321: 


"MAC Protocol Specification". 


[8] 


3GPP TS 25.331: 


"RRC Protocol Specification". 


[9] 


3GPP TS 33.102: 


"Security Architecture". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in [2] apply. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AM Acknowledged Mode 

AMD Acknowledged Mode Data 
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ARQ 


Automatic Repeat Request 


BCCH 


Broadcast Control Channel 


BCH 


Broadcast Channel 


C- 


Control- 


CCCH 


Common Control Channel 


CCH 


Control Channel 


CCTrCH 


Coded Composite Transport Channel 


CRC 


Cyclic Redundancy Check 


CTCH 


Common Traffic Channel 


DCCH 


Dedicated Control Channel 


DCH 


Dedicated Channel 


DL 


Downlink 


DSCH 


Downlink Shared Channel 


DTCH 


Dedicated Traffic Channel 


FACH 


Forward Link Access Channel 


FDD 


Frequency Division Duplex 


LI 


Layer 1 (physical layer) 


L2 


Layer 2 (data link layer) 


L3 


Layer 3 (network layer) 


LI 


Length Indicator 


LSB 


Least Significant Bit 


MAC 


Medium Access Control 


MRW 


Move Receiving Window 


MSB 


Most Significant Bit 


PCCH 


Paging Control Channel 


PCH 


Paging Channel 


PDU 


Protocol Data Unit 


PHY 


Physical layer 


PhyCH 


Physical Channels 


RACH 


Random Access Channel 


RLC 


Radio Link Control 


RRC 


Radio Resource Control 


SAP 


Service Access Point 


SDU 


Service Data Unit 


SHCCH 


Shared Channel Control Channel 


SN 


Sequence Number 


SUFI 


Super Field 


TCH 


Traffic Channel 


TDD 


Time Division Duplex 


TFI 


Transport Format Indicator 


TM 


Transparent Mode 


TMD 


Transparent Mode Data 


TTI 


Transmission Time Interval 


U- 


User- 


UE 


User Equipment 


UL 


Uplink 


UM 


Unacknowledged Mode 


UMD 


Unacknowledged Mode Data 


UMTS 


Universal Mobile Telecommunications System 


UTRA 


UMTS Terrestrial Radio Access 


UTRAN 


UMTS Terrestrial Radio Access Network 



4 General 
4.1 Objective 

This subclause describes the architecture of the RLC sublayer. 
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4.2 



Overview of the RLC sublayer architecture 



The model presented in this subclause is intended to support the definition of the RLC sublayer only, and is not meant 
to specify or constrain the implementation of the protocol. The RLC sublayer consists of RLC entities, of which there 
are three types: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM) RLC entities 



Figure 4.1 illustrates different RLC entities in the RLC model. 

An UM and a TM RLC entity can be configured to be a transmitting RLC entity or a receiving RLC entity. The 
transmitting RLC entity transmits RLC PDUs and the receiving RLC entity receives RLC PDUs. An AM RLC entity 
consists of a transmitting side, and a receiving side, where the transmitting side of the AM RLC entity transmits RLC 
PDUs and the receiving side of the AM RLC entity receives RLC PDUs. 

Elementary procedures (see clause 1 1) are defined between a "Sender" and a "Receiver". In UM and TM, the 
transmitting RLC entity acts as a Sender and the peer RLC entity acts as a Receiver. An AM RLC entity acts either as a 
Sender or as a Receiver depending on the elementary procedure. The Sender is the transmitter of AMD PDUs and the 
Receiver is the receiver of AMD PDUs. A Sender or a Receiver can reside at either the UE or the UTRAN. 

There is one transmitting and one receiving RLC entity for each transparent mode (TM) and unacknowledged mode 
(UM) service. There is one combined, transmitting and receiving entity for the acknowledged mode (AM) service. 

In this specification, "transmitted" is equivalent to "submitted to the lower layer" unless otherwise explicitly stated. 
Each RLC UM, and TM entity uses one logical channel to send or receive data PDUs. An AM RLC entity can be 
configured to use one or two logical channels to send or receive data and control PDUs. If two logical channels are 
configured, they are of the same type (DCCH or DTCH). In figure 4.1, the dashed lines between the AM-Entities 
illustrate the possibility to send and receive RLC PDUs on separate logical channels, e.g. control PDUs on one and data 
PDUs on the other. A more detailed description of the different entities is given in subclauses 4.2.1.1, 4.2.1.2 and 
4.2.1.3. 



4.2.1 



Model of the RLC sublayer 
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Higher layer RLC MAC 




Figure 4.1: Overview model of the RLC sublayer 
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4.2.1.1 



Transparent mode (TM) RLC entities 



Figure 4.2 below shows the model of two transparent mode peer RLC entities. The logical channels used to 
communicate with the lower layer are different depending on the placement of the RLC entity (at the UE or the 
UTRAN) described in the figure below. 



UE/UTRAN 



Radio Interface (Uu) 



UTRAN/UE 



TM-SAP 




Transmitting 
TM- RLC 
entity 



Receiving 
TM- RLC 
entity 



Reassembly 



CCCH/DCCH/DTCH/SHCCH- UE 
BCCH/PCCH/DCCH/ DTCH- UTRAN 




TM-SAP 



Reception 
buffer 



CCCH/DCCH/DTCH/SHCCH - UTRAN 
BCCH/PCCH/DCCH/DTCH - UE 



Figure 4.2: Model of two transparent mode peer entities 



4.2.1.1.1 Transmitting TM RLC entity 

The transmitting TM-RLC entity receives RLC SDUs from upper layers through the TM-SAP. 

All received RLC SDUs must be of a length that is a multiple of one of the valid TMD PDU lengths. 

If segmentation has been configured by upper layers and a RLC SDU is larger than the TMD PDU size used by the 
lower layer for that TTI, the transmitting TM RLC entity segments RLC SDUs to fit the TMD PDUs size without 
adding RLC headers. All the TMD PDUs carrying one RLC SDU are sent in the same TTI, and no segment from 
another RLC SDU are sent in this TTI. 

If segmentation has not been configured by upper layers, then more than one RLC SDU can be sent in one TTI by 
placing one RLC SDU in one TMD PDU. All TMD PDUs in one TTI must be of equal length. 

When the processing of a RLC SDU is complete, the resulting one or more TMD PDU(s) are/is submitted to the lower 
layer through either a BCCH, DCCH, PCCH, CCCH, SHCCH or a DTCH logical channel. 
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Receiving TM RLC entity 



The receiving TM-RJLC entity receives TMD PDUs through the configured logical channels from the lower layer. If 
segmentation is configured by upper layers, all TMD PDUs received within one TTI are reassembled to form the RLC 
SDU. 

If segmentation is not configured by upper layers, each TMD PDU is treated as a RLC SDU. 
The receiving TM RLC entity delivers RLC SDUs to upper layers through the TM-SAP. 

4.2.1.2 Unacknowledged mode (UM) RLC entities 

Figure 4.3 below shows the model of two unacknowledged mode peer RLC entities. 

UE/UTRAN 



Radio Interface (Uu) 



< 



UM -SAP 



> 









Transm issio n 
buffer 








Segmentation & 
C oncatenation 








Add R LC header 








C ip he ring 








Transm ittin 
g 

UM RLC 
entity 



R eceiving 
UM RLC 
entity 




UTRAN/UE 



UM-SAP 



R eassem bly 



Remove RLC 
header 



R eception 
buffer 



Deciphering 



DCCH/DTCH - UE DCCH/DTCH - UTRAN 

CCCH/SHCCH/DCCH/DTCH/CTCH - UTRAN C C C H/S H C C H/D C C H/DTC H/C TC H - UE 

Figure 4.3: Model of two unacknowledged mode peer entities 



4.2. 1 .2. 1 Transmitting UM RLC entity 

The transmitting UM-RLC entity receives RLC SDUs from upper layers through the UM-SAP. 

The transmitting UM RLC entity segments the RLC SDU into UMD PDUs of appropriate size, if the RLC SDU is 
larger than the length of available space in the UMD PDU. The UMD PDU may contain segmented and/or concatenated 
RLC SDUs. UMD PDU may also contain padding to ensure that it is of a valid length. Length Indicators are used to 
define boundaries between RLC SDUs within UMD PDUs. Length Indicators are also used to define whether Padding 
is included in the UMD PDU. 

If ciphering is configured and started, an UMD PDU is ciphered (except for the UMD PDU header) before it is 
submitted to the lower layer. 

The transmitting UM RLC entity submits UMD PDUs to the lower layer through either a CCCH, SHCCH, DCCH, 
CTCH or a DTCH logical channel. 

4.2.1.2.2 Receiving UM RLC entity 

The receiving UM-RLC entity receives UMD PDUs through the configured logical channels from the lower layer. 
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The receiving UM RLC entity deciphers (if ciphering is configured and started) the received UMD PDUs (except for 
the UMD PDU header). It removes RLC headers from received UMD PDUs, and reassembles RLC SDUs (if 
segmentation and/or concatenation has been performed by the transmitting UM RLC entity). 

RLC SDUs are delivered by the receiving UM RLC entity to the upper layers through the UM-SAP. 

4.2.1.3 Acknowledged mode (AM) RLC entity 

Figure 4.4 below shows the model of an acknowledged mode RLC entity. 

The AM RLC entity can be configured to utilize one or two logical channels. The figure 4.4 shows the model of the AM 
RLC entity when one logical channel (shown as a solid line) and when two logical channels (shown as dashed lines) are 
used. 

If one logical channel is configured, the transmitting side of the AM RLC entity submits AMD and Control PDUs to the 
lower layer on that logical channel. And the RLC PDU size shall be the same for AMD PDUs and control PDUs. 

In case two logical channels are configured in the uplink, AMD PDUs are transmitted on the first logical channel, and 
control PDUs are transmitted on the second logical channel. In case two logical channels are configured in the downlink, 
AMD and Control PDUs can be transmitted on any of the two logical channels. 




Figure 4.4: Model of an acknowledged mode entity 
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4.2.1.3.1 



Transmitting side 



The transmitting side of the AM-RLC entity receives RLC SDUs from upper layers through the AM-SAP. 

RLC SDUs are segmented and/or concatenated into AMD PDUs of a fixed length. The segmentation is performed if the 
received RLC SDU is larger than the length of available space in the AMD PDU. The AMD PDU size is a semi-static 
value that is configured by upper layers and can be changed through the modification of the AM RLC entity by upper 
layers. The AMD PDU may contain segmented and/or concatenated RLC SDUs. The AMD PDU may also contain 
Padding to ensure that it is of a valid size. Length Indicators are used to define boundaries between RLC SDUs within 
AMD PDUs, Length Indicators are also used to define whether Padding or Piggybacked STATUS PDU is included in 
the AMD PDU. 

After the segmentation and/or concatenation are performed, the AMD PDUs are placed in the Retransmission buffer 
and at the MUX. 

AMD PDUs buffered in the Retransmission buffer are deleted or retransmitted based on the status report found within a 
STATUS PDU or Piggybacked STATUS PDU sent by the peer AM RLC entity. This status report may contain positive 
or negative acknowledgements of individual AMD PDUs received by the peer AM RLC entity. 

The MUX multiplexes AMD PDUs from the Retransmission buffer that need to be retransmitted, and the newly 
generated AMD PDUs delivered from the Segmentation/Concatenation function. 

The PDUs are delivered to the function that completes the AMD PDU header and potentially replaces padding with 
piggybacked status information. The padding in the AMD PDU may be replaced by the Piggybacked STATUS PDU 
that may be delivered from the Reception buffer at the receiving side of the AM RLC entity. A Piggybacked STATUS 
PDUs can be of variable size in order to match the amount of free space in the AMD PDU. The AMD PDU header is 
completed based on the input from the RLC Control Unit that indicates the values to set in various fields (e.g. Polling 
Bit). The function also multiplexes, if required, Control PDUs received from the RLC Control Unit (RESET and 
RESET ACK PDUs), and from the Reception buffer (Piggybacked STATUS and STATUS PDUs), with AMD PDUs. 

The ciphering (if configured) is then applied to the AMD PDUs. The AMD PDU header is not ciphered. Piggybacked 
STATUS PDU and Padding in AMD PDU (when present) are ciphered. Control PDUs (i.e. STATUS PDU, RESET 
PDU, and RESET ACK PDU) are not ciphered. 

The transmitting side of the AM RLC entity submits AMD PDUs to the lower layer through either one or two DCCH or 
DTCH logical channels. 

4.2. 1 .3.2 Receiving side 

The receiving side of the AM-RLC entity receives AMD and Control PDUs through the configured logical channels 
from the lower layer. 

AMD PDUs are routed to the Deciphering Unit, where AMD PDUs (minus th£AMD PDU header) are deciphered (if 
ciphering is configured and started), and then delivered to the Reception buffer. 

The AMD PDUs are placed in the Reception buffer until a complete RLC SDU has been received. The Receiver 
acknowledges successful reception or requests retransmission of the missing AMD PDUs by sending one or more 
STATUS PDUs to the AM RLC peer entity, through its transmitting side. If a Piggybacked STATUS PDU is found in 
an AMD PDU, it is delivered to the Retransmission buffer & Management Unit at the transmitting side of the AM RLC 
entity, in order to purge the buffer of positively acknowledged AMD PDUs, and to indicate which AMD PDUs need to 
be retransmitted. 

Once a complete RLC SDU has been received, the associated AMD PDUs are reassembled by the Reassembly Unit and 
delivered to upper layers through the AM-SAP. 

RESET and RESET ACK PDUs are delivered to the RLC Control Unit for processing. If a response to the peer AM 
RLC entity is needed, an appropriate Control PDU is delivered, by the RLC Control Unit to the transmitting side of the 
AM RLC entity. The received STATUS PDUs are delivered to the Retransmission buffer and Management Unit at the 
transmitting side of the AM RLC entity, in order to purge the buffer of positively acknowledged AMD PDUs, and to 
indicate which AMD PDUs need to be retransmitted. 
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5 Functions 

The following functions are supported by RLC sublayer. For an overall description of the following functions see [3]: 

- Segmentation and reassembly. 

- Concatenation. 

- Padding. 

- Transfer of user data. 

- Error correction. 

- In-sequence delivery of upper layer PDUs. 

- Duplicate detection. 
Flow control. 
Sequence number check. 

- Protocol error detection and recovery. 

- Ciphering. 

- SDU discard. 
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6 Services provided to upper layers 

This clause describes the different services provided by RLC sublayer to upper layers. It also includes the mapping of 
RLC functions to different RLC services. For a detailed description of the RLC services see [3]. 

- Transparent data transfer Service: 

The following functions are needed to support transparent data transfer: 

- Segmentation and reassembly. 

- Transfer of user data. 

- SDU discard. 

- Unacknowledged data transfer Service: 

The following functions are needed to support unacknowledged data transfer: 

- Segmentation and reassembly. 

- Concatenation. 

- Padding. 

- - Transfer of user data. 

- Ciphering. 

- Sequence number check. 

- SDU discard. 

- Acknowledged data transfer Service: 

The following functions are needed to support acknowledged data transfer: 
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- Segmentation and reassembly. 

- Concatenation. 

- Padding. 

- Transfer of user data. 

- Error correction. 

- In-sequence delivery of upper layer PDUs. 

- Duplicate detection. 

- Flow Control. 

- Protocol error detection and recovery. 

- Ciphering. 

- SDU discard. 

- Maintenance of QoS as defined by upper layers. 
Notification of unrecoverable errors. 

6.1 Mapping of services/functions onto logical channels 

The following tables show the applicability of services and functions to the logical channels in UL/DL and UE/UTRAN. 
A in a column denotes that the service/function is applicable for the logical channel in question whereas a '-' denotes 
that the service/function is not applicable. 



Table 6.1: RLC modes and functions in UE uplink side 



Service 


Functions 


CCCH 


SHCCH 


DCCH 


DTCH 


Transparent 
Service 


Applicability 




+ 


+ 


+ 


Segmentation 








+ 


Transfer of user data 


+ 


+ 


+ 


+ 


SDU Discard 






+ 


+ 


Unacknowledged 
Service 


Applicability 








+ 


Segmentation 






+ 


+ 


Concatenation 






+ 


+ 


Padding 








+ 


Transfer of user data 






+ 


+ 


Ciphering 






+ 


+ 


SDU Discard 








+ 


Acknowledged 
Service 


Applicability 






+ 


+ 


Segmentation 






+ 


+ 


Concatenation 






+ 


+ 


Padding 






+ 


+ 


Transfer of user data 






+ 


+ 


Flow Control 






+ 


+ 


Error Correction 






+ 


+ 


Protocol error correction & 
recovery 






+ 


+ 


Ciphering 






+ 


+ 


SDU Discard 






+ 


+ 
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Table 6.2: RLC modes and functions in UE downlink side 



Service 


Functions 


BCCH 


PCCH 


SHCCH 


CCCH 


DCCH 


DTCH 


CTCH 


Transparent 
Service 


Applicability 




+ 






+ 


+ 


- 


Reassembly 


* 








+ 


+ 


- 


Transfer of user data 


+ 


+ 






+ 


+ 


- 


Unacknowledged 
Service 


Applicability 


* 




+ 


+ 


+ 


+ 


+ 


Reassembly 


* 




+ 


+ 


+ 


+ 


+ 


Deciphering 










+ 


+ 




Sequence number check 


- 


- 


+ 


+ 


+ 


+ 


+ 


Transfer of user data 


- 


- 


+ 


+ 


+ 


+ 


+ 


Acknowledged 
Service 


Applicability 


- 


- 


- 


- 


+ 


+ 


- 


Reassembly 


- 


- 


- 


- 


+ 


+ 


- 


Error correction 










+ 


+ 




Flow Control 










+ 


+ 




In sequence delivery 










+ 


+ 




Duplicate detection 










+ 


+ 




Protocol error correction 
& recovery 










+ 


+ 




Deciphering 










+ 


+ 




Transfer of user data 










+ 


+ 




SDU Discard 










+ 


+ 




- Table 6.3: RLC modes and functions in UTRAN downlink side 


Service 


Functions 


BCCH 


PCCH 


CCCH 


SHCCH 


DCCH 


DTCH 


CTCH 


Transparent 
Service 


Applicability 


+ 








+ 


+ 




Segmentation 










+ 


+ 




Transfer of user data 


+ 


+ 






+ 


+ 




SDU Discard 










+ 


+ 




Unacknowledged 
Service 


Applicability 






+ 


+ 


+ 


+ 


+ 


Segmentation 








+ 


+ 


+ 


+ 


Concatenation 






+ 


+ 


+ 


+ 


+ 


Padding 






+ 


+ 




+ 


+ 


Ciphering 










+ 


+ 




Transfer of user data 






+ 


+ 


+ 


+ 


+ 


SDU Discard 










+ 






Acknowledged 
Service 


Applicability 










+ 


+ 




Segmentation 










+ 


+ 




Concatenation 










+ 


+ 




Padding 










+ 


+ 




Transfer of user data 










+ 


+ 




Flow Control 










+ 


+ 




Error Correction 










+ 


+ 




Protocol error correction 
& recovery 










+ 


+ 




Ciphering 










+ 


+ 




SDU Discard 










+ 


+ 
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Table 6.4: RLC modes and functions in UTRAN uplink side 



Service 


Functions 


CCCH 


SHCCH 


OCCH 


DTCH 


Transparent 
Service 


Applicability 


+ 


+ 


+ 


+ 


Reassembly 


- 


- 


+ 


+ 


Transfer of user data 


+ 


+ 


+ 


+ 


Unacknowledged 
Service 


Applicability 


- 


- 


+ 


+ 


Reassembly 


- 


- 


+ 


+ 


Deciphering 






+ 


+ 


Sequence number check 


— : — 


- 


+ 


+ 


Transfer of user data 


- 


- 


+ 


+ 


Acknowledged 
Service 


Applicability 


- 


- 


+ 


+ 


Reassembly 










Error correction 






+ 


+ 


Flow Control 






+ 


+ 


In sequence delivery 








+ 


Duplicate detection 






+ 


+ 


Protocol error correction & 
recovery 






+ 


+ 


Deciphering 






+ 


+ 


Transfer of user data 








+ 



7 Services expected from MAC 

For a detailed description of the service provided by the MAC sublayer to upper layers see [3]. 
Data transfer. 



8 Elements for layer-to-layer communication 

The interaction between the RLC sublayer and other layers are described in terms of primitives where the primitives 
represent the logical exchange of information and control between the RLC sublayer and other layers. The primitives 
shall not specify or constrain the implementation. 



8.1 Primitives between RLC and upper layers 

The primitives between RLC and upper layers are shown in Table 8.1. 



Table 8.1: Primitives between RLC and upper layers 



Generic Name 


Parameters 


Req. 


Ind. 


Resp. 


Conf. 


RLC -AM -DATA 


Data. CNF, MUI 


Data, Discardlnfo 


Not Defined 


MUI 


RLC-UM-DATA 


Data, Use special LI 


Data 


Not Defined 


Not Defined 


RLC-TM-DATA 


Data 


Data 


Not Defined 


Not Defined 


CRLC-CONFIG 


E/R, Stop, Continue, 
Ciphering Elements 

(UM/AM only), 
TM_parameters (TM 
only), UM_parameters 

(UM only). 
AM_parameters (AM 
only) 


Not Defined 


Not Defined 


Not Defined 


CRLC-SUSPEND 
(UM/AM only) 


N 


Not Defined 


Not Defined 


VT(US) (UM only), 
VT(S) (AM only) 


CRLC-RESUME 
(UM/AM only) 


No Parameter 


Not Defined 


Not Defined 


Not Defined 


CRLC-STATUS 


Not Defined 


EVC 


Not Defined 


Not Defined 



Each Primitive is defined as follows: 
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RLC-AM-DATA-Req/Ind/Conf 

- RLC-AM-DATA-Req is used by upper layers to request transmission of an RLC SDU in acknowledged mode. 

- RLC-AM-DATA-Ind is used by the AM RLC entity to deliver to upper layers an RLC SDU that has been 
transmitted in acknowledged mode and to indicate to upper layers of the discarded RLC SDU in the peer RLC 
AM entity. 

- RLC-AM-DATA-Conf is used by the AM RLC entity to confirm to upper layers the reception of an RLC SDU 
by the peer-RLC AM entity. 

RLC-UM-DATA-Req/Ind 

- RLC-UM-DATA-Req is used by upper layers to request transmission of an RLC SDU in unacknowledged mode. 

- RLC-UM-DATA-Ind is used by the UM RLC entity to deliver to upper layers an RLC SDU that has been 
transmitted in unacknowledged mode. 

RLC-TM-DATA-Req/Ind 

- RLC-TM-DATA-Req is used by upper layers to request transmission of an RLC SDU in transparent mode. 

- RLC-TM-DATA-Ind is used by W TM RLC entity to deliver to upper layers an RLC SDU that has been 
transmitted in transparent mode. 

CRLC-CONFIG-Req 

This primitive is used by upper layers to establish, re-establish, release, stop, continue or modify the RLC. Ciphering 
elements are included for UM and AM operation. 

CRLC-SUSPEND-Req/Conf 

- CRLC-SUSPEND-Req is used by upper layers to suspend the UM or AM RLC entity. 

- CRLC-SUSPEND-Conf is used by the UM or AM RLC entity to confirm that the entity is suspended. 
CRLC-RESUME-Req 

This primitive is used by upper layers to resume the UM or AM RLC entity after the UM or AM RLC entity has been 
suspended. 

CRLC-STATUS-Ind 

It is used by an RLC entity to send status information to upper layers. 

8.2 Primitive parameters 

Following parameters are used in the primitives: 

1) The parameter Data is the RLC SDU that is mapped onto the Data field in RLC PDUs. When AM or UM RLC 
entities are used, the length of the Data parameter is a multiple of 8 bits, otherwise (TM RLC entity) the length 
of Data parameter is a bit-string whose length may not be a multiple of 8 bits. 

2) The parameter Confirmation Request (CNF) indicates whether the transmitting side of the AM RLC entity needs 

- to confirm the reception of the RLC SDU by the peer-RLC AM entity. If required, once all AMD PDUs that 
make up the RLC SDU are positively acknowledged by the receiving AM RLC entity, the transmitting AM RLC 
entity notifies upper layers. 

3) The parameter Message Unit Identifier (MUI) is an identity of the RLC SDU, which is used to indicate which 
RLC SDU that is confirmed with the RLC-AM-DATA-Conf. primitive. 

4) The parameter E/R indicates establishment, re-establishment, release or modification of an RLC entity, where re- 
establishment is applicable to AM and UM RLC entities only. If re-establishment is requested the state variables 
and configurable parameters are initialised according to subclause 9.7.7. If release is requested, all protocol 
parameters, variables and timers are released and the RLC entity enters the NULL state. If modification is 
requested the protocol parameters indicated by upper layers (e.g. ciphering parameters) are only modified, while 
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keeping the other protocol parameters, such as the protocol variables, protocol timers and protocol state 
unchanged. AM RLC entities are always re-established if the AMD PDU size is changed. The modification of 
other protocol parameters does not require a re-establishment. 

5) The parameter Event Code (EVC) indicates the reason for the CRLC-STATUS-Ind (e.g., unrecoverable errors 
such as data link layer loss or recoverable status events such as reset.). 

6) The parameter Ciphering Elements are only applicable for UM and AM operations. These parameters are 
Ciphering Mode, Ciphering Key, Transmitting Activation Time (SN to activate a new ciphering configuration at 
the Sender), Receiving Activation Time (SN to activate a new ciphering configuration at the Receiver) and HFN 
(Hyper Frame Number). 

7) The AM_parameters are only applicable for AM operation. These parameters are AMD PDU size, In-sequence 
Delivery Indication (indicating that RLC SDUs are delivered to upper layers in sequence or out of sequence), 
Timer values (see subclause 9.5), Protocol parameter values (see subclause 9.6), Polling triggers (see subclause 
9.7.1), Status triggers (see subclause 9.7.2), Periodical Status blocking configuration (see subclause 9.7.2), SDU 
discard mode (see subclause 9.7.3), Minimum WSN (see subclause 9.2.2.1 1.3), and Send MRW. The Minimum 
WSN is always greater than or equal to the number of transport blocks in the smallest transport block set. The 
Send MRW indicates that the information of each discarded RLC SDU is sent to the Receiver, and the MRW 
SUFI is sent to the Receiver even if no segments of the RLC SDU to be discarded were submitted to a lower 
layer. v 

8) The parameter Discardlnfo indicates to upper layer the discarded RLC SDU in the peer-RLC AM entity. It is 
applicable only when in-sequence delivery is configured and it is to be used when upper layers require the 
reliable data transfer. 

9) The Stop parameter indicates to the RLC entity to (see subclause 9.7.6): 

- discard all RLC PDUs received from the lower layer. 

- not submit to lower layer any RLC PDUs. 

10) The Continue parameter indicates to the RLC entity to continue transmission and reception of RLC PDUs. 

1 l)The parameter Use special LI indicates that the LI indicating that an RLC SDU begins in the beginning of an 
RLC PDU is to be used (see subclause 9.2.2.8). 

12) The UM_parameters are only applicable for UM operation. It contains Timer_Discard value (see subclause 9.5) 
and largest UMD PDU size (see subclause 9.2.2.8). 

13) The TM_parameters are only applicable for TM operation. It contains e.g. segmentation indication (see 
subclauses 9.2.2.9 and 1 1.1.2.1), Timer_Discard value (see subclause 9.5) and delivery of erroneous SDU 
indication (see subclause 1 1 . 1 .3). 

14) The N parameter indicates that an RLC entity will not send a PDU with SN>=VT(S)+N for AM and 
SN>=VT(US)+N for UM, where N is a non-negative integer. 

15) The VT(S) parameter indicates the value of the Send State Variable for the case of the AM. 

16) The VT(US) parameter indicates the value of the UM Data State Variable, for the case of the UM. 



9 Elements for peer-to-peer communication 
9.1 Protocol data units 

The structures defined in this subclause are normative. 

9.1.1 Data PDUs 

a) TMD PDU (Transparent Mode Data PDU). 
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The TMD PDU is used to convey RLC SDU data without adding any RLC overhead. The TMD PDU is used by 
RLC when it is in transparent mode. 

b) UMD PDU (Unacknowledged Mode Data PDU). 

The UMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. It is used by RLC 
when using unacknowledged data transfer. 

c) AMD PDU (Acknowledged Mode Data PDU). 

The AMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. The AMD PDU is 
used by RLC when it is in acknowledged mode. 

9.1.2 Control PDUs 

a) STATUS PDU and Piggybacked STATUS PDU 

The STATUS PDU and the Piggybacked STATUS PDU are used in acknowledged mode: 

- by the Receiver to inform the Sender about missing and received AMD PDUs in the Receiver; 

- by the Receiver to inform the^ender about the size of the allowed transmission window; 

- by the Sender to request the Receiver to move the reception window; and 

- by the Receiver to acknowledge the Sender about the reception of the request to move the reception window. 

b) RESET PDU 

The RESET PDU is used in acknowledged mode to reset all protocol states, protocol variables and protocol 
timers of the peer RLC entity in order to synchronise the two peer entities. 

c) RESET ACK PDU 

The RESET ACK PDU is an acknowledgement to the RESET PDU. 



Table 9.1: RLC PDU names and descriptions 



Data Transfer Mode 


PDU name 


Description 


Transparent 


TMD 


Transparent mode data 


Unacknowledged 


UMD 


Sequenced unacknowledqed mode data 


Acknowledged 


AMD 


Sequenced acknowledqed mode data 


STATUS 


Solicited or Unsolicited Status Report, Change 
window size command, SDU discard command, or 
SDU discard acknowledgement 


Piggybacked 
STATUS 


Piggybacked Solicited or Unsolicited Status Report, 
Change window size command, SDU discard 
command, or SDU discard acknowledgement 


RESET 


Reset Command 


RESET ACK 


Reset Acknowledgement 



9.2 Formats and parameters 

The formats of PDUs and their parameters defined in this subclause are normative. 

9.2.1 Formats 

This subclause specifies the format of the RLC PDUs. The parameters of each PDU are explained in subclause 9.2.2. 
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9.2.1.1 General 

An RLC PDU is a bit string. In the figures in subclause 9.2, bit strings are represented by tables in which the first bit is 
the leftmost one on the first line of the table, the last bit is the rightmost one on the last line of the table, and more 
generally the bit string is to be read from left to right and then in the reading order of the lines. 

Depending on the provided service, RLC SDUs are bit strings, with any non-null length, or bit strings with a multiple of 
8 bits in length. An RLC SDU is included into an RLC PDU from first bit onward. 



9.2.1.2 TMD PDU 

The TMD PDU is used to transfer user data when RLC is operating in transparent mode. No overhead is added to the 
SDU by RLC. The data length is not constrained to be a multiple of 8 bits. 

Data 

Figure 9.1: TMD PDU 



9.2.1.3 



UMD PDU 



The UMD PDU is used to transfer user data when RLC is operating in unacknowledged mode. The length of the data 
part shall be a multiple of 8 bits. The UMD PDU header consists of the first octet, which contains theJSequence 
Number". The RLC header consists of the first octet and all the octets that contain "Length Indicators". 



Sequence Number 



Length Indicator 



Octl 



(Optional) (1) 



Length Indicator 



Data 



PAD 



(Optional) 



Last Octet 



(Optional) 



Figure 9.2: UMD PDU 



NOTE (1): The "Length Indicator" may be 15 bits. 



9.2.1.4 AMD PDU 

The AMD PDU is used to transfer user data, piggybacked status information and the Polling bit when RLC is operating 
in acknowledged mode. The length of the data part shall be a multiple of 8 bits. The AMD PDU header consists of the 
first two octets, which contain the "Sequence Number". The RLC header consists of the first two octets and all the 
octets that contain "Length Indicators". 
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D/C 



Sequence Number 



Sequence Number 



HE 



Length Indicator 



Octl 
Oct2 

Oct3 (Optional) (1) 



Length Indicator 



Data 



PAD or a piggybacked STATUS PDU 



OctN 



NOTE (1): The "Length Indicator" may be 1 5 bits. 

Figure 9.3: AMD PDU 

9.2.1.5 STATUS PDU 

The STATUS PDU is used to report the status between two RLC AM entities. 

The format of the STATUS PDU is given in Figure 9.4 below. The Figure shows an example of STATUS PDU and the 
length of each SUFI is dependent on the SUFI type. 



D/C PDU type 



SUFI, 



SUFI 



SUFIk 



PAD 



Oct 1 
Oct2 



OctN 



Figure 9.4: STATUS PDU 

Up to K super-fields (SUFI, -SUFIk) can be included into one STATUS PDU, in which each super-field can be of 
different type. The size of a STATUS PDU is variable and upper bounded by the maximum RLC PDU size used by the 
logical channel on which the control PDUs are sent. Padding shall be included to exactly fit one of the PDU sizes used 
by the logical channel on which the control PDUs are sent. The length of the STATUS PDU shall be a multiple of 8 bits. 



9.2.1.6 



Piggybacked STATUS PDU 



The format of the piggybacked STATUS PDU is the same as for STATUS PDU except that the D/C field is replaced by 
a reserved bit (R2). This PDU can be piggybacked in an AMD PDU if the data does not fill the complete AMD PDU. 
The PDU Type field is set to "000" and all other values are invalid for this version of the protocol and the PDU is 
discarded. 
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R2 PDUType 



SUFI, 



SUFI, 



SUFI K 



PAD 



Octl 
Oct2 



OctN 



9.2.1.7 



Figure 9.5: Piggybacked STATUS PDU 
RESET, RESET ACK PDU 



The RESET PDU (the RESET ACK PDU) have a one-bit sequence number field (RSN) in order to know whether or 
not it is a retransmission of a previous RESET PDU (of a previous RESET ACK PDU). 



V 

D/C PDU Type 


RSN 


Rl 


HFNI 


HFNI 


HFNI 






PAD 





Octl 



OctN 



Figure 9.6: RESET, RESET ACK PDU 

The size of a RESET or RESET ACK PDU is variable and upper bounded by the maximum RLC PDU size used by the 
logical channel on which the control PDUs are sent. Padding shall be included to exactly fit one of the PDU sizes used 
by the logical channel on which the control PDUs are sent. The length of the RESET or RESET ACK PDU shall be a 
multiple of 8 bits. 

9.2.2 Parameters 

If not otherwise mentioned in the definition of each field then the bits in the parameters shall be interpreted as follows: 
the left-most bit string is the first and most significant and the right most bit is the last and least significant bit. 

Unless otherwise mentioned, integers are encoded"in standard binary encoding for unsigned integers. In all cases, 
including when a value extends over more than one octet as shown in the tables, the bits appear ordered from MSB to 
LSB when read in the PDU. 

9.2.2.1 D/C field 

Length: Ibit. 

The D/C field indicates the type of an AM PDU. It can be either data or control PDU. 



Bit 


Description 


0 


Control PDU 


1 


Data PDU 



9.2.2.2 PDU Type 

Length: 3 bit. 
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The PDU type field indicates the Control PDU type. 



Bit 


PDU Type 


000 


STATUS 


001 


RESET 


010 


RESET ACK 


011-111 


Reserved 
(PDUs with this 
coding will be 
discarded by 
this version of 
the protocol). 



9.2.2.3 Sequence Number (SN) 

This field indicates the "Sequence Number" of the PDU, encoded in binary. 



PDU type 


Length 


Notes 


AMD PDU 


12 bits 


Used for retransmission and reassembly 


UMD PDU 


7 bits 


Used for reassembly 



9.2.2.4 Polling bit (P) 

Length: 1 bit. 

This field is used to request a status report (one or several STATUS PDUs) from the Receiver. 



Bit 


Description 


0 


Status report not requested 


1 


Request a status report 



9.2.2.5 Extension bit (E) 

Length: Ibit. 

This bit indicates if the next octet will be a "Length Indicator" and E bit. 



Bit 


Description 


0 


The next field is data, piggybacked STATUS 
PDU or padding 


1 


The next field is Length Indicator and E bit 



9.2.2.6 Reserved 1 (R1) 

Length: 3 bits. 

This field in the RESET PDU and RESET ACK PDU is used to have a multiple of 8 bits in length and for this purpose 
it is coded as "000". Other functions of it are left for future releases. 

9.2.2.7 Header Extension Type (HE) 

Length: 2 bits. 

This two-bit field indicates if the next octet will be data or a "Length Indicator" and E bit. 
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Value 


Description 


00 


The succeeding octet contains data 


01 


The succeeding octet contains a length indicator and E 
bit 


10-11 


Reserved (PDUs with this coding will be discarded by 
this version of the protocol). 



9.2.2.8 Length Indicator (LI) 

The "Length Indicator" is used to indicate, each time, the end of an RLC SDU occurs in the PDU. 

Unless for the predefined values reserved for special purposes and listed in the tables below, the "Length Indicator" 
shall: 

- be set to the number of octets between the end of the RLC header and up to and including the octet at the end of 
an RLC SDU segment; 

- be included in the PDUs that they refer to. 

The size of the "Length Indicator" may be either 7bits or 15 bits. The value of a "Length Indicator" shall not exceed the 
values specified in subclauses 1 1.2.4.2 and 1 1.3.4.5. 

The "Length Indicators", which refer to the same PDU shall: 

not be reordered nor removed in case of retransmission; 

- be in the same order as the RLC SDUs that they refer to. 
For AM: 

- if the "AMD PDU size" is < 126 octets: 

- 7-bit "Length Indicators" shall be used. 

- else: 

- 15-bit "Length Indicators" shall be used; 

- the size of the "Length Indicator" is always the same for all AMD PDUs, for one RLC entity. 
For UM: 

- if the "largest UMD PDU size" is < 125 octets: 

- 7-bit "Length Indicators" shall be used. 

- else: 

15-bit "Length Indicators" shall be used; 

- between modifications of the "largest UMD PDU size", the size of the "Length Indicator" is the same for all 
UMD PDUs; 

- if the parameter Use special LI is configured; and 

- if the RLC SDU begins in the beginning of the RLC PDU; and 

- if the "Length Indicators" indicating that a RLC SDU ended exactly in the end or one octet short (only when 15- 
bit "Length Indicators" is used) of the previous RLC PDU is not present: 

- if 7-bit "Length Indicator" is used: 

- the "Length Indicator" with value "111 1 100" shall be used; 

- if 15-bit "Length Indicator" is used: 
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- the "Length Indicator" with value "111 1111 1111 1 100" shall be used. 

In the case where the end of the last segment of an RLC SDU exactly ends at the end of a PDU and there is no "Length 
Indicator" that indicates the end of the RLC SDU: 

- if 7-bit "Length Indicator" is used: 

- a "Length Indicator" with value "000 0000" shall be placed as the first "Length Indicator" in the following 
PDU; 

- if 15-bit "Length Indicator" is used: 

- a "Length Indicator" with value "000 0000 0000 0000" shall be placed as the first "Length Indicator" in the 
following PDU. 

In case this RLC SDU was the last one to be transmitted, an RLC PDU may be transmitted. This RLC PDU consists of: 

- an RLC Header; 

- if 7-bit "Length Indicator" is used: 

- a "Length Indicator" with value "000 0000"; 

- if 15-bit "Length Indicator" is used: 

- a "Length Indicator" with value "000 0000 0000 0000"; 
a padding "Length Indicator"; and 

padding. 

In the case where a PDU contains a 15-bit "Length Indicator" indicating that an RLC SDU ends with one octet left in 
the PDU, the last octet of this PDU shall: 

- be padded by the Sender and ignored by the Receiver though there is no "Length Indicator" indicating the 
existence of Padding; and 

- not be filled with the first octet of the next RLC SDU data. 

In the case where 15-bit "Length Indicators" are used for the previous PDU and the last segment of an RLC SDU is one 
octet short of exactly filling the PDU: 

- if a 15-bit "Length Indicator" is used for the following PDU: 

- the "Length Indicator" with value "111 1111 1111 1011" shall be placed as the first "Length Indicator" in the 
following PDU; 

- the remaining one octet in the previous PDU shall be padded by the Sender and ignored at the Receiver 
though there is no "Length Indicator" indicating the existence of Padding; 

- in case this SDU was the last one to be transmitted: 

- a RLC PDU consisting of an RLC Header with "Length Indicator" "111 1111 1111 1011" followed by a 
padding "Length Indicator" and padding may be transmitted; 

- if a 7-bit "Length Indicator" is used for the following PDU: 

- if RLC is configured for UM mode: 

- the "Length Indicator" with value "000 0000" shall be placed as the first "Length indicator" in the 
following PDU and its SN shall be incremented by 2 before it is transmitted. 

Predefined values of the "Length Indicator" are used to indicate padding. The values that are reserved for special 
purposes are listed in the tables below depending on the size of the "Length Indicator". Only predefined "Length 
Indicator" values can refer to the padding space. These values shall only be placed after all other "Length Indicators" for 
a PDU. 
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STATUS PDUs can be piggybacked on the AMD PDU by using part or all of the padding space. A "Length Indicator" 
shall be used to indicate the piggybacked STATUS PDU. This "Length Indicator" takes space from the padding space 
or piggybacked STATUS PDU and not the PDU data and will always be the last Length Indicator. Where only part of 
the padding space is used by a piggybacked STATUS PDU, the end of the piggybacked STATUS PDU is determined 
by one of the SUFI fields NO_MORE or ACK, thus no additional "Length Indicator" is required to show that there is 
still padding in the PDU. The padding/piggybacked STATUS PDU predefined "Length Indicators" shall be added after 
the very last "Length Indicator" that indicates the end of the last RLC SDU segment in the PDU. 

If "SDU discard with explicit signalling" is configured: 

- an AMD PDU can contain a maximum number of 15 "Length Indicators" indicating the end of 15 corresponding 
SDUs; and 

- the rest of the AMD PDU space shall be used as padding or as piggybacked STATUS PDU. 
Length: 7 bits 



Bit 


Description 


0000000 


The previous RLC PDU was exactly filled with the last segment of an RLC SDU 
and there is no "Length Indicator" that indicates the end of the RLC SDU in the 
previous RLC PDU. 


1111100 


UMD PDU:%The first data octet in this RLC PDU is the first octet of an RLC 
SDU. AMD PDU: Reserved (PDUs with this coding will be discarded by this 
version of the protocol). 


1111101 


Reserved (PDUs with this coding will be discarded by this version of the 
protocol). 


1111110 


AMD PDU: The rest of the RLC PDU includes a piggybacked STATUS PDU. 
UMD PDU: Reserved (PDUs with this coding will be discarded by this version 
of the protocol). 


1111111 


The rest of the RLC PDU is padding. The padding length can be zero. 



Length: I5bits 



Bit 


Description 


000000000000000 


The previous RLC PDU was exactly filled with the last segment of an 
RLC SDU and there is no "Length Indicator" that indicates the end of 
the RLC SDU in the previous RLC PDU. 


111111111111011 


The last segment of an RLC SDU was one octet short of exactly filling 
the previous RLC PDU and there is no "Length Indicator" that indicates 
the end of the RLC SDU in the previous RLC PDU. The remaining one 
octet in the previous RLC PDU is ignored. 


111111111111100 


UMD PDU: The first data octet in this RLC PDU is the first octet of an 
RLC SDU. AMD PDU: Reserved (PDUs with this coding will be 
discarded by this version of the protocol). 


111111111111101 


Reserved (PDUs with this coding will be discarded by this version of the 
protocol). 


111111111111110 


AMD PDU: The rest of the RLC PDU includes a piggybacked STATUS 
PDU. UMD PDU: Reserved (PDUs with this coding will be discarded by 
this version of the protocol). 


111111111111111 


The rest of the RLC PDU is padding. The padding length can be zero. 



9.2.2.9 Data field 

RLC SDUs or segments of RLC SDUs are mapped to this field in transparent, unacknowledged and acknowledged 
modes. 

Transparent mode data: 

- the length of RLC SDUs is not constrained to a multiple of 8 bits; 

- if "Segmentation" is configured: 

- all the RLC PDUs carrying one RLC SDU shall be sent in one TTI; 
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- only segments from one RLC SDU shall be sent in one TTI; 

- otherwise (Segmentation is not configured): 

- TMD PDU size is fixed within a single TTI and is equal to the RLC SDU size. 
Unacknowledged mode data and Acknowledged mode data: 

- the length of RLC SDUs is constrained to a multiple of 8 bits; 

- if an RLC SDU is segmented: 

- its last segment shall be concatenated with the first segment of the next RLC SDU in order to fill the data 
field completely and avoid unnecessary padding. The "Length Indicator" field is used to point the borders 
between RLC SDUs; 

- for PDUs with 15-bit "Length Indicators": 

if an RLC SDU ends with one octet left in a PDU whether the "Length Indicator" indicating the end of the 
RLC SDU is contained in this PDU or in the next PDU: 

- padding for the last octet of this PDU is necessary and the next RLC SDU shall not be concatenated in 
this PDU. No "Length Indicator" shall be needed to indicate this kind of one-octet padding. 

9.2.2.10 Padding (PAD) 

All unused space in a PDU shall be located at the end of the PDU and is referred to as padding. Padding has a length 
such that the PDU has the required predefined total length. 

Padding may have any value and the Receiver shall disregard it. 

9.2.2.11 SUFI 

Which SUFI fields to use is implementation dependent, but when a STATUS PDU includes information about which 
PDUs have been received and which are detected as missing, information shall not be included about PDUs with 
SN>VR(H) i.e. PDUs that have not yet reached the Receiver. Information about PDUs with SN<VR(R) shall not be 
given except when this is necessary in order to use the BITMAP SUFI, see subclause 9.2.2.1 1.5. 

Length: variable number of bits. 

The SUFI can include three sub-fields: type information (type of super-field, e.g. list, bitmap, acknowledgement, etc), 
length information (providing the length of a variable length field within the following value field) and a value. 

Figure 9.7 shows the structure of the super-field. The size of the type subrfield is non-zero but the size of the other 
sub-fields may be zero. 

T ype 
Length 
Value 



Figure 9.7: The Structure of a Super-Field 

The length of the type field is 4 bits and it may have any of following values. 
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Bit 


Description 


0000 


No More Data (NO MORE) 


0001 


Window Size (WINDOW) 


0010 


Acknowledgement (ACK) 


0011 


List (LIST) 


0100 


Bitmap (BITMAP) 


0101 


Relative list (Rlist) 


0110 


Move Receiving Window (MRW) 


0111 


Move Receiving Window Acknowledgement 
(MRW_ACK) 


1000- 

1111 


Reserved (PDUs with this encoding are invalid for this 
version of the protocol) 



The length sub-field gives the length of the variable size part of the following value sub-field and the length of it 
depends on the super-field type. The value sub-field includes the value of the super-field, e.g. the bitmap in case of a 
BITMAP super-field, and the length is given by the length of the type sub-field. 

9.2.2. 1 1 . 1 The No More Data super-field 

The 'No More Data' super-field indicates the end of the data part of a STATUS PDU and is shown in Figure 9.8 below. 
It shall always be placed as the last SUFI if it is included in a STATUS PDU. All data after this SUFI shall be regarded 
as padding and shall be neglected. 

| Type=NO_MORE | 
Figure 9.8: NO_MORE field in a STATUS PDU 

9.2.2. 11.2 The Acknowledgement super-field 

The 'Acknowledgement 1 super-field consists of a type identifier field (ACK) and a sequence number (LSN) as shown in 
Figure 9.9 below. The acknowledgement super-field is also indicating the end of the data part of a STATUS PDU. Thus, 
no 'NO MORE' super-field is needed in the STATUS PDU when the 'ACK' super- field is present. The ACK SUFI shall 
always be placed as the last SUFI if it is included in a STATUS PDU. All data after this SUFI shall be regarded as 
padding and shall be neglected. 

Type = ACK 

LSN 



Figure 9.9: The ACK fields in a STATUS PDU 

LSN 

Length: 12 bits 

Acknowledges the reception of all PDUs with "Sequence Number" < LSN (Last Sequence Number) that are not 
indicated to be erroneous in earlier parts of the STATUS PDU. This means that if the LSN is set to a value greater than 
VR(R), all erroneous PDUs shall be included in the same STATUS PDU and if the LSN is set to VR(R), the erroneous 
PDUs can be split into several STATUS PDUs. At the transmitter, if the value of the LSN =< the value of the first error 
indicated in the STATUS PDU, VT(A) will be updated according to the LSN, otherwise VT(A) will be updated 
according to the first error indicated in the STATUS PDU. VT(A) is only updated based on STATUS PDUs where 
ACK SUFI (or MRW_ACK SUFI) is included. The LSN shall not be set to a value > VR(H) nor < VR(R). 

9.2.2. 1 1 .3 The Window Size super-field 

The Window Size super-field consists of a type identifier (WINDOW) and a window size number (WSN) as shown in 
Figure 9.10 below. The Receiver is always allowed to change the transmission window size of the peer entity during a 
connection, but the minimum and the maximum allowed value is given by upper layers configuration. The reception 
window size of the Receiver is not changed. 
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Type = WINDOW 
WSN 

Figure 9.10: The WINDOW fields in a STATUS PDU 

WSN 

Length: 12 bits 

The value of VT(WS) to be used by the transmitter. The range of the WSN is [0, 2 12 -1]. The minimum value of VT(WS) 
is 1. If WSN is zero the SUFI shall be discarded by this version of the protocol. The variable VT(WS) is set equal to 
WSN upon reception of this SUFI. If WSN is greater than Configured_Tx_Window_Size, VT(WS) shall be set equal to 
Configured_Tx_Window_Size. 

9.2.2. 1 1 .4 The List super-field 

The List Super-Field consists of a type identifier field (LIST), a list length field (LENGTH) and a list of LENGTH 
number of pairs as shown in Figure 9. 1 1 below: 

^ I Type = LIST 

LENGTH 

SNi 

_U 

SN 2 

_L2 

SNlength 

Llength 

Figure 9.11: The List fields in a STATUS PDU 

LENGTH 

Length: 4 bits 

The number of (SN, , L,)-pairs in the super-field of type LIST. The value "0000" is invalid and the STATUS PDU is 
discarded. 

SN, 

Length: 12 bits 

"Sequence Number" of PDU, which was not correctly received. 
U 

Length: 4 bits 

Number of consecutive PDUs not correctly received following PDU with "Sequence Number" SN /t 

9.2.2.11.5 The Bitmap super-field 

The Bitmap Super-Field consists of a type identifier field (BITMAP), a bitmap length field (LENGTH), a first sequence 
number (FSN) and a bitmap as shown in Figure 9. 12 below: 

Type = BITMAP 

LENGTH 

FSN 

Bitmap 

Figure 9.12: The Bitmap fields in a STATUS PDU 
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LENGTH 

Length: 4 bits 

The size of the bitmap in octets equals LENGTH+1, i.e. LENGTH="0000" means that the size of the bitmap is one 
octet and LENGTH= M 1111" gives the maximum bitmap size of 1 6 octets. 

FSN 

Length: 12 bits 

The "Sequence Number" for the first bit in the bitmap. FSN shall not be set to a value lower than VR(R)-7 when the 
reception window size is less than half the maximum RLC AM "Sequence Number". If the reception window size is 
larger, FSN shall not be set to a value lower than VR(R). 

Bitmap 

Length: Variable number of octets given by the LENGTH field. 

Status of the SNs in the interval [FSN, FSN + (LENGTH+1 )*8 - 1] indicated in the bitmap where each position (from 
left to right) can have two different values (0 and 1) with the following meaning (bit_positione[0,(LENGTH+l)*8 - 1]): 

1 : SN - (FSN + bit_position) has been correctly received. 

0: SN = (FSN + bitjosition) has not been correctly received. 

9.2.2. 11.6 The Relative List super-field 

The Relative List super-field consists of a type identifier field (RLIST), a list length field (LENGTH), the first sequence 
number (FSN) and a list of LENGTH number of codewords (CW) as shown in Figure 9. 13 below. 

Type = RLIST 

LENGTH 

FSN 

CWi 

CW 2 

CWlength 

Figure 9.13: The RList fields in a STATUS PDU 

LENGTH 

Length: 4 bits 

The number of codewords (CW) in the super- field of type RLIST. 
FSN 

Length: 12 bits 

The "Sequence Number" for the first erroneous PDU in the RLIST, i.e. LENGTH="0000" means that only FSN is 
present in the SUFL 

CW 

Length: 4 bits 

The CW consists of 4 bits where the three first bits are part of a number and the last bit is a status indicator and it shall 
be interpreted as follows: 
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Code Word 
X1X2X3 0 


Description 

Next 3 bits of the number are x 1 x 2 x 3 and the number continues in the next 
CW. The most significant bit within this CW is 


X1X2X3 1 


Next 3 bits of the number are X!X 2 X 3 and the number is terminated. The 
most significant bit within this CW is x x . This is the most significant CW 
within the number. 



By default, the number given by the CWs represents a distance between the previous indicated erroneous PDU up to 
and including the next erroneous PDU. 

One special value of CW is defined: 

000 1 'Error burst indicator 1 . 

The error burst indicator means that the next CWs will represent the number of subsequent erroneous PDUs^not 
counting the already indicated error position). After the number of errors in a burst is terminated with XXX 1, the next 
codeword will again by default be the least significant bits (LSB) of the distance to the next error. 

If the last CW, as indicated by the value of the LENGTH field, does not contain a "1" in its rightmost position, or the 
last CW, as indicated by the value of the LENGTH field does contain a "1" in its rightmost position, but is a special 
"error burst indicator" CW, the encoding of the RLIST SUFI is invalid, and the STATUS PDU is discarded. 

9.2.2.1 1 .7 The Move Receiving Window Acknowledgement super-field 

The 'Move Receiving Window Acknowledgement' super-field acknowledges the reception of a MRW SUFI. The format 
is given in Figure 9. 14 below. 

Type = MRW_ACK 

_N 

SN ACK 



Figure 9.14: The MRW-ACK fields in a STATUS PDU 

N 

Length: 4 bits 

The N field shall be set equal to the N LENG th field in the received MRW SUFI if the SN ACK field is equal to the 
SN_MRW LENGTH field. Otherwise N shall be set to 0. 

With the aid of this field in combination with the SN_ACK field, it can be determined if the MRW_ACK corresponds 
to a previously transmitted MRW SUFI. 

SN_ACK 

Length: 12 bits 

The SN_ACK field indicates the updated value of VR(R) after the reception of the MRW SUFI. With the aid of this 
field in combination with the N field, it can be determined if the MRW_ACK corresponds to a previously transmitted 
MRW SUFI. 

9.2.2.1 1 ,8 The Move Receiving Window (MRW) super-field 

The 'Move Receiving Window 1 super-field is used to request the Receiver to move its reception window and optionally 
to indicate the set of discarded RLC SDUs, as a result of an RLC SDU discard in the Sender. The format is given in 
Figure 9. 1 5 below. 
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Type = MRW 
LENGTH 
SN MRWi 
SN_MRW 2 

SN MRWleng™ 

N LENGTH 



Figure 9.15: The MRW fields in a STATUS PDU 

LENGTH 

Length: 4 bits 

The number of SN MRWj fields in the super-field of type MRW. 

The values "0001" through "1111" indicate 1 through 15 SN_MRW ; respectively. The value "0000" indicates that one 
SN MRWi field is present and that the RLC SDU to be discarded in the Receiver extends above the configured 
transmission window in the Sender. 

SN_MRWi * 
Length: 12 bits 

When Send MRW is configured, an SN_MRWj shall be used to indicate the end of each discarded RLC SDU, i.e. the 
number of SNJvlRWi fields shall equal the number of RLC SDUs discarded by that MRW SUFI. When Send MRW is 
not configured, SN MRW; shall be used to indicate the end of the last RLC SDU to be discarded in the Receiver and 
they may optionally be used to indicate the end of other discarded RLC SDUs. SN_MRW ; is the "Sequence Number" of 
the PDU that contains the "Length Indicator" of the i:th RLC SDU to be discarded in the Receiver (except for 
SN_MRW length when N LEN gth = 0, see definition of N LENGTH )- The order of the SN_MRWi shall be in the same 
sequential order as the RLC SDUs that they refer to. 

Additionally SN_MRW LENG th requests the Receiver to discard all PDUs with "Sequence Number" < SN_MRW LENG th, 
and to move the reception window accordingly. In addition, when Nlength > 0, the Receiver has to discard the first 
N LEN GTH "Length Indicators'* and the corresponding data octets in the PDU with "Sequence Number" SN_MRW LE ngth. 

Nlength 
Length: 4 bits 

Nlength is used together with SN Jv1RW LE ngth to indicate the end of the last RLC SDU to be discarded in the Receiver. 

Nlength indicates which "Length Indicator" in the PDU with "Sequence Number" SN_MRW LE ngth corresponds to the 
last RLC SDU to be discarded in the Receiver. N LEN gth = 0 indicates that the last RLC SDU ended in the PDU with 
"Sequence Number" SN_MRW LE ngth -1 and that the first data octet in the PDU with "Sequence Number" 
SN_MRW LE ngth is the first data octet to be reassembled next. 

9.2.2.12 Reserved 2 (R2) 

Length: 1 bit 

This bit in the Piggybacked STATUS PDU is used to make the Piggybacked STATUS PDU a multiple of 8 bits in 
length and for this purpose it is coded as 0. Otherwise the PDU is treated as invalid and hence shall be discarded by this 
version of the protocol. 

9.2.2. 1 3 Reset Sequence Number (RSN) 

Length: 1 bit 

This field is used to indicate the sequence number of the transmitted RESET PDU. If this RESET PDU is a 
retransmission of the original RESET PDU then the retransmitted RESET PDU would have the same RSN value as the 
original RESET PDU. Otherwise it will have the next RSN value. The initial value of this field is zero. The value of this 
field shall be reinitialised when the RLC is re-established. It shall not be reinitialised when the RLC is reset. 
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9.2.2.14 Hyper Frame Number Indicator (HFNI) 

Length: 20 bit 

This field is used to indicate the hyper frame number (HFN) to the peer entity. With the aid of this field the HFN in UE 
and UTRAN can be synchronised. 

9.3 Protocol states 

The content presented in this subclause is intended to support the definition of the RLC protocol states only, and is not 
meant to specify or constrain the implementation of the protocol. 

9.3.1 State model for transparent mode entities 

Figure 9.16 illustrates the state model for transparent mode RLC entities (both transmitting and receiving). A 
transparent mode entity can be in one of the following states. 

9.3.1.1 NULL State 

In the NULL state the RLC entity does not exist and therefore it is not possible to transfer any data through it. 
Upon reception of a CRLC-CONFIG-Req from upper layers indicating establishment, the RLC entity: 
is created; and 

- enters the DATA_TRANSFER_READY state. 

9.3.1 .2 DATA_TRANSFER_READY State 

In the DATA_TRANSFER_READY state, transparent mode data can be exchanged between the entities according to 
subclause 11.1. 

Upon reception of a CRLC-CONFIG-Req from upper layer indicating release, the RLC entity: 

- enters the NULL state; and 

- is considered as being terminated. 



CRLC-CONFIG-Req 




Received signal 
CRLC-CONFIG-R eq Sent signal 

Figure 9.16: The state model for transparent mode entities 

9.3.2 State model for unacknowledged mode entities 

Figure 9. 17 illustrates the state model for unacknowledged mode RLC entities (both transmitting and receiving). An 
unacknowledged mode entity can be in one of the following states. 
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9.3.2.1 NULL State 

In the NULL state the RLC entity does not exist and therefore it is not possible to transfer any data through it. 
Upon reception of a CRLC-CONFIG-Req from upper layer indicating establishment the RLC entity: 
is created; and 

- enters the DATA_TRANSFER_READY state. 

9.3.2.2 DATA_TRANSFER_READY State 

In the D ATATRAN SFER_RE AD Y state, unacknowledged mode data can be exchanged between the entities 
according to subclause 1 1.2. 

Upon reception of a CRLC-CONFIG-Req from upper layer indicating release, the RLC entity: 

- enters the NULL state; and 

- is considered as being terminated. 

Upon reception of a CRLC-CONFIG-Req from upper layer indicating modification, the RLC entity: 

- stays in the DATA_TRANSFER_READY state; 

- modifies only the protocol parameters and timers as indicated by upper layers. 
Upon reception of a CRLC-SUSPEND-Req from upper layers, the RLC entity: 

- enters the LOCAL_SUSPEND state. 

9.3.2.3 LOCAL_SUSPEND State 

In the LOCAL_SUSPEND state, the RLC entity is suspended, i.e. it does not send UMD PDUs with SN greater than 
equal to certain specified value (see subclause 9.7.5). 

Upon reception of a CRLC-RESUME-Req from upper layers, the RLC entity: 

- enters the DATA_TRANSFER_READY state; and 

- resumes the data transmission. 

Upon reception of a CRLC-CONFIG-Req from upper layer indicating modification, the RLC entity: 

- stays in the LOCAL_SUSPEND state; 

- modifies only the protocol parameters and timers as indicated by upper layers. 
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CRLC-CONFIG-Req 




CRLC-CONFIG-Req 



Sent signal 



CRLC-CONFIG-Req 



Figure 9.17: Ttie state model for unacknowledged mode entities 



9.3.3 



State model for acknowledged mode entities 



Figure 9.18 illustrates the state model for the acknowledged mode RLC entity (both transmitting and receiving). An 
acknowledged mode entity can be in one of the following states. 



In the NULL state the RLC entity does not exist and therefore it is not possible to transfer any data through it 
Upon reception of a CRLC-CONFIG-Req from upper layer indicating establishment, the RLC entity: 
is created; and 
- enters the DATA TRANSFER READY state. 



In the DATA_TRANSFER_READY state, acknowledged mode data can be exchanged between the entities according 
to subclause 1 1.3. 

Upon reception of a CRLC-CONFIG-Req from upper layer indicating release, the RLC entity: 

- enters the NULL state; and 

- is considered as being terminated. 

Upon detection of an initiating condition for the RLC reset procedure described in subclause 1 1.4.2, the RLC entity: 

- initiates the RLC reset procedure (see subclause 1 1.4); and 

- enters the RESET_PENDING state. 

Upon reception of a RESET PDU, the RLC entity responds according to subclause 1 1.4.3. 
Upon reception of a RESET ACK PDU, the RLC entity takes no action. 

Upon reception of CRLC-SUSPEND-Req from upper layer, the RLC entity is suspended and enters the 
LOCAL_SUSPEND state. 



9.3.3.1 



NULL State 



9.3.3.2 



DATA TRANSFER READY State 
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9.3.3.3 



RESET PENDING State 



In the RESET_PENDING state the entity waits for a response from its peer entity and no data can be exchanged 
between the entities. 

Upon reception of a CRLC-CONFIG-Req from upper layer indicating release, the RLC entity: 

- enters the NULL state; and 

- is considered as being terminated. 

Upon reception of a RESET ACK PDU with the same RSN value as in the corresponding RESET PDU, the RLC entity: 

- acts according to subclause 1 1 .4.4; and 

- enters the DATA_TRANSFER_READY state. 

Upon reception of a RESET ACK PDU with a different RSN value as in the corresponding RESET PDU, the RLC 
entity: 

- discards the RESET ACK PDU (see subclause 1 1 .4.4); and 

- stays in the RESET_PENDING state. 
Upon reception of a RESET PDU, the RLC entity: 

- responds according to subclause 1 1 .4.3; and 

- stays in the RESET_PENDING state. 

Upon reception of CRLC-SUSPEND-Req from upper layer, the RLC entity: 

- enters the RESET_AND_SUSPEND state. 
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CRLC-CONFIG-Req 




CRJLC-CONFIG-Req 



Sent signal 



Figure 9.18: The state model for the acknowledged mode entities 

9.3.3.4 LOCAL_SUSPEND State 

In the LOCAL_SUSPEND state, the RLC entity is suspended, i.e. it does not send AMD PDUs with SN greater than or 
equal to certain specified value (see subclause 9.7,5). 

Upon reception of CRLC-RESUME-Req from upper layers in this state, the RLC entity: 

- resumes the data transmission; and 

- enters the DATA_TRANSFER_READY state. 

Upon reception of CRLC-CONFIG-Req from upper layers indicating release, the RLC entity: 

- enters the NULL state; and 

is considered as being terminated. 
Upon detection of an initiating condition for RLC reset procedure described in subclause 1 1.4.2, the RLC entity: 

- initiates the RLC reset procedure (see subclause 1 1 .4); and 

- enters the RE SET_AND_SU SPEND state. 

9.3.3.5 RESET_AND_SUSPEND State 

In the RESET_ AND S U S P EN D state, the entity waits for a response from its peer entity or a primitive (CRLC- 
RESUME-Req) from its upper layer and no data can be exchanged between the entities. 
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Upon reception of CRLC-CONFIG-Req from upper layer indicating release, the RLC entity: 

- enters the NULL state; and 

- is considered as being terminated. 

Upon reception of a RESET ACK PDU with the same RSN value as in the corresponding RESET PDU, the RLC entity: 

- acts according to subclause 1 1 .4.4; and 

- enters the LOCAL_SUSPEND state. 

Upon reception of CRLC-RESUME-Req from upper layer in this state, the RLC entity: 

- is resumed, i.e. releases the suspend constraint; and 

- enters the RESET_PENDING state. 

9.4 State variables 

The state variables defined in this subclause are normative. 

This sub-clause describes the state variables used in AM and UM in order to specify the peer-to-peer protocol. All state 
variables are non-negative integers. UMD and AMD PDUs are numbered by modulo integer sequence numbers (SN) 
cycling through the field: 0 to 2 12 - 1 for AM and 0 to 2 7 - 1 for UM. All arithmetic operations contained in this 
specification on VT(S), VT(A), VT(MS), VR(R), VR(H) and VR(MR) are affected by the AM modulus: All arithmetic 
operations contained in this specification on VT(US) and VR(US) are affected by the UM modulus. When performing 
arithmetic comparisons of state variables or SN values a modulus base shall be used. This modulus base is subtracted 
(within the appropriate field) from all the values involved and then an absolute comparison is performed. At the Sender, 
VT(A) and VT(US) shall be assumed to be the modulus base in AM and UM respectively. At the Receiver, arithmetic 
comparisons of variables or SN values, VR(R) and VR(US) shall be assumed to be the modulus base in AM and UM 
respectively. 

The RLC shall maintain the following state variables in the Sender. 

a) VT(S) - Send state variable. 

This state variable contains the SN of the next AMD PDU to be transmitted for the first time (i.e. excluding 
retransmitted PDUs). It shall be updated after the aforementioned PDU is transmitted or after transmission of a 
MRW SUFI which includes SN_MRW LENGTH >VT(S) (see subclause 1 1 .6). The initial value of this variable is 0. 

b) VT(A) - Acknowledge state variable. 

This state variable contains the SN following the SN of the last hvsequence acknowledged PDU. This forms the 
lower edge of the window of acceptable acknowledgements. VT(A) shall be updated based on the receipt of a 
STATUS PDU including an ACK (see subclause 9.2.2.1 1.2) and/or an MRW_ACK SUFI (see subclause 1 1.6). 

The initial value of this variable is 0. For the purpose of initialising the protocol, this value shall be assumed to 
be the first SN following the last in-sequence acknowledged PDU. 

c) VT(DAT). 

This state variable counts the number of times a PDU has been transmitted. There shall be one VT(DAT) for 
each PDU and each shall be incremented every time the corresponding PDU is transmitted. 

The initial value of this variable is 0. 

d) VT(MS) - Maximum Send state variable. 

This state variable contains the SN of the first PDU that can be rejected by the peer Receiver, VT(MS) = VT(A) 
+ VT(WS). This value represents the upper edge of the transmit window. The transmitter shall not transmit 
PDUs with SN > VT(MS) unless VT(S) > VT(MS). In that case, the PDU with SN = VT(S) - 1 can also be 
transmitted. VT(MS) shall be updated when VT(A) or VT(WS) is updated. 

The initial value of this variable is Configured_Tx_Window size. 
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e) VT(US) - UM data state variable. 

This state variable contains the SN of the next UMD PDU to be transmitted. It shall be incremented by 1 each 
time a UMD PDU is transmitted. 

The initial value of this variable is 0. 

0 VT(PDU). 

This state variable is used when the "poll every PoIl PDU PDU" polling trigger is configured. It shall be 
incremented by 1 for each PDU that is transmitted including both new and retransmitted PDUs. When it 
becomes equal to the value PolI_PDU, a new poll shall be transmitted and the state variable shall be set to zero. 

The initial value of this variable is 0. 

g) VT(SDU). 

This state variable is used when the "poll every Poll_SDU SDU" polling trigger is configured. It shall be 
incremented by 1 for a given SDU when all the PDUs carrying a part of this SDU have been transmitted at least 
once. When it becomes equal to the value Poll_SDU a new poll shall be transmitted and the state variable shall 
be set to zero. The "Polling bit" shall be set to " 1 " in the first transmission of the PDU that contains the last 
segment of the SDU. v 

The initial value of this variable is 0. 

h) VT(RST) - Reset state variable. 

This state variable is used to count the number of times a RESET PDU is transmitted before the reset procedure 
is completed. VT(RST) shall be incremented by 1 each time a RESET PDU is transmitted. VT(RST) shall only 
be reset upon the reception of a RESET ACK PDU, i.e. VT(RST) shall not be reset when an RLC reset initiated 
by the peer RLC entity occurs. 

The initial value of this variable is 0. 

i) VT(MRW) - MRW command send state variable. 

This state variable is used to count the number of times a MRW command is transmitted. VT(MRW) is 
incremented by I each time an MRW SUFI is transmitted. VT(MRW) shall be reset when the SDU discard with 
explicit signalling procedure is terminated. The initial value of this variable is 0. 

j) VT(WS) - Transmitter window size state variable. 

This state variable contains the size that shall be used for the transmitter window. VT(WS) shall be set equal to 
the WSN field when the transmitter receives a STATUS PDU including a WINDOW SUFI. 

The initial value of this variable is Configured_Tx_Window_size. 

The RLC shall maintain the following state variables in the Receiver: 

a) VR(R) - Receive state variable. 

This state variable contains the SN following that of the last in-sequence PDU received. It shall be updated upon 
the receipt of the PDU with SN equal to VR(R). 

The initial value of this variable is 0. For the purpose of initialising the protocol, this value shall be assumed to 
be the first SN following the last in-sequence received PDU. 

b) VR(H) - Highest expected state variable. 

This state variable contains the SN following the highest SN of any received PDU. When a PDU is received with 
SN x such that VR(H)<x<VR(MR), this state variable shall be set equal to x+1 . 

The initial value of this variable is 0. 

c) VR(MR) - Maximum acceptable Receive state variable. 
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This state variable contains the SN of the first PDU that shall be rejected by the Receiver, VR(MR) = VR(R) + 
Configured_Rx_Window_Size. 

d) VR(US) - Receiver Send Sequence state variable. 

This state variable contains the SN following that of the last PDU received. When a PDU with SN equal to x is 
received, the state variable shall set equal to x + l . 

The initial value of this variable is 0. 

e) VR(EP) - Estimated PDU Counter state variable. 

This state variable contains the number of PDUs whose re- transmission is still expected as a consequence of the 
transmission of the latest status report. At the end of each TTI it is decremented by the total number of PDUs 
that were received during that time. 

9.5 Timers 

The timers defined in this subclause are normative. The timers shall be considered active from the time they are started 
until the time they either expire or are stopped. 

a) Timer_Poll. 

This timer shall only be used when so configured by upper layers. The value of the timer is signalled by upper 
layers. In the UE this timer shall be started when the successful or unsuccessful transmission of a PDU 
containing a poll is indicated by lower layer. In UTRAN it should be started when a PDU containing a poll is 
submitted to lower layer. If x is the value of the state variable VT(S) at the time the poll was submitted to lower 
layer, the timer shall be stopped upon receiving: 

- acknowledgements for all the AMD PDUs with SN up to and including x - l ; or 

- a negative acknowledgement for the PDU with SN = x - l . 

If the timer expires and no STATUS PDU fulfilling the criteria above has been received: 

- the Receiver shall be polled once more; 

- the timer shall be restarted; and 

- the new value of VT(S) shall be saved. 

If a new poll is sent when the timer is active, the timer shall be restarted at the time specified above, and the 
value of VT(S) shall be saved. 

b) Timer_Poll_Prohibit. 

This timer shall only be used when so configured by upper layers. It is used to prohibit transmission of polls 
within a certain period. The value of the timer is signalled by upper layers. 

In the .UE this timer shall be started when the successful or unsuccessful transmission of a PDU containing a poll 
is indicated by lower layer. In UTRAN it should be started when a PDU containing a poll is submitted to lower 
layer. 

From the time a poll is triggered until the timer expires, polling is prohibited. If another poll is triggered while 
polling is prohibited, its transmission shall be delayed until the timer expires (see subclause 9.7. 1). Only one poll 
. shall be transmitted when Timer_Poll_Prohibit expires even if several polls were triggered in the meantime. This 
timer shall not be affected by the reception of STATUS PDUs. 

When Timer_Poll_Prohibit is not configured by upper layers, polling is never prohibited. 

c) Timer_EPC. 

This timer shall only be used when the EPC function is configured by upper layers. It is meant to account for the 
roundtrip delay, i.e. the time between the transmission of a status report and the reception of the first 
retransmitted PDU. The initial value of the timer is signalled by upper layers. 



3GPP 





Release 1999 



43 



3GPP TS 25.322 V3.8.0 (2001-09) 



In the UE, this timer shall be started when the successful or unsuccessful transmission of the first STATUS PDU 
of a status report is indicated by lower layer. In UTRAN it should be started when the first STATUS PDU of a 
status report is submitted to lower layer. Only after Timer EPC expires shall VR(EP) be decremented as 
described in subclause 9.7.4. 

d) Timer_Discard. 

This timer shall be used when timer-based SDU discard is configured by upper layers. The value of the timer is 
signalled by upper layers. In the transmitter, a new timer is started upon reception of an SDU from upper layer. 

In UM/TM, if a timer expires before the corresponding SDU is submitted to lower layer, "SDU discard without 
explicit signalling" specified in subclauses 1 1 .2.4.3 and 11.1 .4.2 shall be initiated. In AM, if a timer expires 
before the corresponding SDU is acknowledged, "SDU discard with explicit signalling" specified in subclause 
1 1 .6 shall be initiated. 

e) Timer_Poll_Periodic. 

This timer shall only be used when "timer based polling" is configured by upper layers. The value of the timer is 
signalled by upper layers. The timer shall be started when the RLC entity is created. When the timer expires, the 
RLC entity shall: 

- restart the timer; * 

if PDUs are available for transmission or retransmission (not yet acknowledged): 

- trigger a poll. 

0 Timer_Status_Prohibit. 

This timer shall only be used when so configured by upper layers. It is meant to prohibit the Receiver from 
sending consecutive acknowledgement status reports. A status report is an acknowledgement status report if it 
contains any of the SUFIs LIST, BITMAP, RLIST or ACK. The value of the timer is signalled by upper layers. 

In the UE, this timer shall be started when the successful or unsuccessful transmission of the last STATUS PDU 
of an acknowledgement status report is indicated by lower layer. In UTRAN it should be started when the last 
STATUS PDU of an acknowledgement status report is submitted to lower layer. 

From the time an acknowledgement status report is triggered until the Timer_Status_Prohibit timer expires, 
acknowledgement is prohibited. If another such status report is triggered while acknowledgement is prohibited, 
its transmission shall be delayed until the timer expires (see subclause 9.7.2). The status report may be updated 
during this time. The transmission of SUFIs MRW, MRW_ACK, WINDOW or NO_MORE is not restricted. 

When Timer_Status_Prohibit is not configured by upper layers, acknowledgment is never prohibited. 

g) Timer_Status_Periodic. 

This timer shall only be used when timer based status reporting is configured by upper layers. 

This timer shall be started when the RLC entity is created. When the timer expires the transmission of a status 
report shall be triggered and the timer shall be restarted. This timer can be blocked by upper layers. The timer 
shall be restarted when upper layers indicate that it is no longer blocked. 

h) Timer_RST. 

This timer is meant to handle the loss of a RESET PDU by the peer entity, or the loss of a RESET ACK PDU 
from the peer entity. The value of the timer is signalled by upper layers. 

In the UE this timer shall be started when the successful or unsuccessful transmission of a RESET PDU is 
indicated by lower layer. In UTRAN it should be started when a RESET PDU is submitted to lower layer. 

« 

Timer_RST shall only be stopped upon reception of a RESET ACK PDU (with same RSN as RESET PDU), i.e. 
this timer shall not be stopped when an RLC reset initiated by the peer RLC entity occurs. If this timer expires, 
the RESET PDU shall be retransmitted. 

i) Timer_MRW. 
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This timer is used to trigger the retransmission of a status report containing an MRW SUFI field. The value of 
the timer is signalled by upper layers. 

In the UE this timer shall be started when the successful or unsuccessful transmission of a STATUS PDU 
containing the MRW SUFI is indicated by lower layer. In UTRAN, it should be started when a STATUS PDU 
containing the MRW SUFI is submitted to lower layer. 

Each time the timer expires the MRW SUFI is retransmitted and the timer is restarted. It shall be stopped when 
one of the termination criteria for the SDU discard with explicit signalling procedure is fulfilled (see subclause 
11.6.4). 



9.6 Protocol Parameters 

The behaviour defined in this subclause is normative. The values of the protocol parameters defined in this subclause 
are signalled by upper layers. 

a) MaxDAT. 

The maximum number of transmissions of a PDU is equal to MaxDAT - 1 . This protocol parameter represents 
the upper limit for state variable VT(DAT). When VT(DAT) equals the value MaxDAT, either RLC RESET 
procedure or SDU discard procedure shall be initiated according to the configuration by upper layers. 

b) Poll_PDU. 

This protocol parameter indicates how often the transmitter shall poll the Receiver in the case where "polling 
every Poll_PDU PDU" is configured by upper layers. It represents the upper limit for the state variable 
VT(PDU). When VT(PDU) equals the value Poll_PDU a poll shall be transmitted to the peer entity. 

c) Poll_SDU. 

This protocol parameter indicates how often the transmitter shall poll the Receiver in the case where "polling 
every Poll_SDU SDU" is configured by upper layers. It represents the upper limit for state variable VT(SDU). 
When VT(SDU) equals the value Poll_SDU a poll shall be transmitted to the peer entity. 

d) Poll_Window. 

This protocol parameter indicates when the transmitter shall poll the Receiver in the case where "window-based 
polling" is configured by upper layers. The range of values of this parameter shall be 0 < Poll_Window < 100. A 
poll is triggered for each PDU when J > Poll_Window, where J is the window transmission percentage defined as: 

(4096+ VT(S) - VT(A)) mod 4096 
J= VT(WS) ^ *100, 

where the constant 4096 is the modulus for AM described in subclause 9.4. 

e) MaxRST. 

The maximum number of transmissions of a RESET PDU is equal to MaxRST - 1. This protocol parameter 
represents the upper limit for state variable VT(RST). When VT(RST) equals the value MaxRST, unrecoverable 
error shall be indicated to upper layers. 

0 Configured_Tx_Window_Size. 

This protocol parameter indicates both the maximum allowed transmitter window size and the value for the state 
variable VT(WS). 

g) Configured_Rx_Window_Size. 

This protocol parameter indicates the receiver window size. 

h) MaxMRW. 
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The maximum number of transmissions of a MRW command is equal to MaxMRW - 1. This protocol parameter 
represents the upper limit for state variable VT(MRW). When VT(MRW) equals the value MaxMRW, the RJLC 
RESET procedure shall be initiated. 

9.7 Specific functions 

The functions defined in this subclause are normative. 

9.7.1 Polling function for acknowledged mode 

The Polling function is used by the Sender to request the peer RLC entity for a status report. The "Polling bit" in the 
AMD PDU indicates the poll request. There are several triggers for initiating the Polling function. Which of the triggers 
shall be used is configured by upper layers for each RLC entity. The following triggers can be configured: 

1) Last PDU in buffer. 

The Sender triggers the Polling function when the last PDU available for transmission is submitted to lower layer. 

2) Last PDU in Retransmission buffer. 

The Sender triggers the Polling function when the last PDU to be retransmitted is submitted to lower layer. 

3) Poll timer. 

The timer TimerPoll is started and stopped according to subclause 9.5 a). When the timer Timer_PolI expires 
the Sender triggers the Polling function. 

4) Every Poll_PDU PDU. 

The Sender triggers the Polling function for every Poll PDU PDU. Both retransmitted and new PDUs shall be 
counted. 

5) Every Poli_SDU SDU. 

The Sender triggers the Polling function for every PoIl SDU SDU. 

6) Window based. 

The Sender triggers the Polling function when the condition described in subclause 9.6 d) ("PoIIWindow") is 
fulfilled. 

7) Timer based. 

The Sender triggers the Polling function periodically. 

Either the triggers 1) and 2) or the trigger 7) should be configured for every RLC entity to avoid deadlock situations. 

The Poll Prohibit function is used by the Sender to delay the initiation of the Polling function. Usage of the Poll Prohibit 
function is configured by upper layers. The Poll Prohibit function consists of starting the timer Timer PolLProhibit 
according to subclause 9.5 b) and delaying the Polling function according to the following rules: 

When the Polling function is triggered, the Sender shall: 

- if polling is not prohibited (see subclause 9.5 b)); and 

- if there is one or more AMD PDUs to be transmitted or there are AMD PDUs not acknowledged by the Receiver: 

initiate the Polling function by setting the polling bit according to subclause 1 1 .3.2. 1.1. 
Upon expiry of the timer Timer_Poll_Prohibit, the Sender shall: 

- if the Polling function was triggered at least once while the timer Timer_Poll_Prohibit was active; and 

- if there is one or more AMD PDUs to be transmitted or there are AMD PDUs not acknowledged by the Receiver: 
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- initiate the Polling function once by setting the polling bit according to subclause 1 1 .3.2. 1 . 1 . 



9.7.2 



STATUS transmission for acknowledged mode 



The Receiver of transmits status reports to the Sender in order to inform the Sender about which AMD PDUs have been 
received and not received. Each status report consists of one or several STATUS PDUs. The Receiver shall always send 
a status report when receiving a poll request. Additionally, the following triggers for transmission of status reports are 
configurable by upper layers: 

1) Detection of missing PDU(s). 

If the Receiver detects one or several missing AMD PDUs it shall trigger the transmission of a status report to 
the Sender. 

2) Timer based status report transfer. 

The Receiver triggers the transmission of a status report to the Sender periodically. The timer 
TimerStatusPeriodic controls the time period according to subclause 9.5 g). When "Periodical Status 
blocking" is configured by upper layers, the trigger shall not be active. 

3) The EPC mechanism. ^ 

The timer Timer_EPC is started according to subclause 9.5 c) and the state variable VR(EP) is set and decreased 
according to subclause 9.7.4. If not all AMD PDUs requested for retransmission have been received before the 
variable VR(EP) equalled zero, a new status report is triggered by the Receiver. A more detailed description of 
the EPC mechanism is given in subclause 9.7.4. 

There are two functions that can prohibit the Receiver from sending a status report containing any of the SUFIs LIST, 
BITMAP, RLIST or ACK. Status reports containing other SUFIs are not prohibited. Upper layers control which 
functions should be used for each RLC entity. If any of the following functions is used the transmission of the status 
report shall be delayed, even if any of the triggering conditions above are fulfilled: 

1) STATUS prohibit. 

The timer Timer_Status_Prohibit is started according to subclause 9.5 0- The Receiver is not allowed to transmit 
a status report while acknowledgement is prohibited (see subclause 9.5 f))- If a status report was triggered during 
this time, the status report is transmitted after the timer Timer_Status_Prohibit has expired, as described below. 

2) The EPC mechanism. 

If the "EPC mechanism" is active and the transmission of a status report is triggered it shall be delayed until the 
"EPC mechanism" has ended, as described below. 

When a status report is triggered the Receiver shall: 

if transmission of status reports is not prohibited by any of the functions "STATUS prohibit" or "EPC 
mechanism": 

assemble and transmit the status report to the Sender, as specified in subclause 1 1 .5.2.2 and 1 1 .5.2.3. 

- otherwise (if the status report is prohibited by at least one of the functions "STATUS prohibit" or "EPC 
mechanism"): 

- if MRW, MRWACK or WINDOW SUFIs are required in the status report: 

- send a status report immediately excluding ACK, LIST, BITMAP, and RLIST SUFIs; 

- if ACK, LIST, BITMAP, or RLIST SUFIs are required in the status report: 

- delay sending these SUFIs until the prohibit function terminates. 

Upon expiry of the timer TimerStatusProhibit or termination of the "EPC mechanism", the Receiver shall: 

if at least one status report was triggered during the time the transmission of a status reports was prohibited that 
could not be transmitted due to prohibition; and 
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- if transmission of a status reports is no longer prohibited by any of the functions "STATUS prohibit" or "EPC 
mechanism": 

- transmit one status report to the Sender, using the procedure described in subclause 1 1 .5.2.3. 

9.7.3 SDU discard function for acknowledged, unacknowledged, and 
transparent mode 

The SDU discard function is used by the Sender to discharge RLC PDUs from the RLC PDU buffer, when the 
transmission of the RLC PDUs does not succeed for a period of time or for a number of transmissions. The SDU 
discard function allows to avoid buffer overflow. There are several alternative operation modes of the RLC SDU 
discard function. Upper layers control, which discard function shall be used for each RLC entity. 

The following is a list of operation modes for the RLC SDU discard function, which are described in detail in the 
subsequent subclauses. 



Table 9.2: List of criteria that control when to perform SDU discard 



Operation mode 


Presence 


Timer based discard, with, explicit signalling 


Network controlled 


Timer based discard, without explicit signalling 


Network controlled 


SDU discard after MaxDAT number of transmissions 


Network controlled 


No discard after MaxDAT number of transmissions 


Network controlled 



9.7.3.1 Timer based discard, with explicit signalling 

This alternative is only applicable to RLC entities operating in acknowledged mode. It uses a timer based triggering of 
SDU discard (Timer_Discard). This makes the SDU discard function insensitive to variations in the channel rate and 
provides means for exact definition of maximum delay. However, the SDU loss rate of the connection is increased as 
SDUs are discarded. 

For every SDU received from upper layers, the Sender shall: 

- start a timer TimerJDiscard. 

When the timer TimerJDiscard of a SDU expires, the Sender shall: 

- discard the SDU; 

- if "Send MRW" is configured, or one or more segments of the discarded SDU were submitted to the lower layer: 
- utilise explicit signalling to inform the Receiver according to subclause 1 1 .6. 

9.7.3.2 Timer based discard, without explicit signalling 

This alternative is only applicable to RLC entities operating in unacknowledged or transparent mode. It uses the same 
timer based trigger for SDU discard (Timer_Discard) as the one described in the subclause 9.7.3.1. The difference is 
that this discard method does, not use any peer-to-peer signalling. 

For every SDU received from upper layers, the Sender shall: 

- start timer monitoring of the transmission time of the SDU. 

When the transmission time exceeds the configured value for a SDU, the Sender shall: 

- discard the SDU without explicit signalling (for RLC entities operating in unacknowledged mode apply 
subclause 1 1.2.4.3 for updating the state variables). 
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9.7.3.3 SDU discard after MaxDAT number of transmissions 

This alternative uses the number of transmissions as a trigger for SDU discard, and is therefore only applicable for 
acknowledged mode RLC. This makes the SDU discard function dependent on the channel rate. Also, this variant of the 
SDU discard function strives to keep the SDU loss rate constant for the connection, on the cost of a variable delay. 

If MaxDAT number of transmissions is reached for an AMD PDU, the Sender shall: 

- discard all SDUs segments of which are contained in the AMD PDU; and 

- utilise explicit signalling to inform the Receiver according to clause 1 1 .6. 

9.7.3.4 No_discard after MaxDAT number of transmissions 

This alternative uses the number of transmissions, and is therefore only applicable for acknowledged mode RLC. 
If MaxDAT number of transmissions is reached for an AMD PDU, the Sender shall: 

- initiate the RLC Reset procedure (see subclause 1 1.3.4.4). 

9.7.3.5 SDU discard notconfigured 

If SDU discard has not been configured for an unacknowledged mode RLC entity, SDUs in the transmitter shall not be 
discarded unless the Transmission buffer is full. 

When the Transmission buffer in an unacknowledged mode RLC entity is full, the Sender may: 

- if segments of the SDU to be discarded have been submitted to lower layer: 

- discard the SDU without explicit signalling according to subclause 1 1.2.4.3. 

- otherwise, if no segments of the SDU to be discarded have been submitted to lower layer: 

- remove the SDU from the Transmission buffer without utilising any of the discard procedures. 

If SDU discard has not been configured for a transparent mode RLC entity, the Sender shall upon reception of new 
SDUs from upper layer: 

- discard all SDUs received from upper layer in previous TTIs that are not yet submitted to lower layer; 

- submit the new SDUs in the first possible TTI. 

For an acknowledged mode RLC entity, an SDU discard mode is always configured. 

9.7.4 The Estimated PDU Counter for acknowledged mode 

The Estimated PDU Counter (EPC) is only applicable for RLC entities operating in acknowledged mode. The EPC is a 
mechanism configured by upper layers used for scheduling the retransmission of status reports in the Receiver. With 
this mechanism, the Receiver will send a new status report in which it requests for AMD PDUs not yet received. The 
time between two subsequent status report retransmissions is not fixed, but it is controlled by both the timer Timer_EPC 
and the state variable VR(EP), which adapt this time to the round trip delay and the current bit rate, indicated in the TFI, 
in order to minimise the delay of the status report retransmission. 

When a status report is triggered by some mechanisms and it is submitted to lower layer (in UTRAN) or the successful 
or unsuccessful transmission of it is indicated by lower layer (in UE) to request for retransmitting one or more missing 
AMD PDUs, the variable VR(EP) is set equal to the number of requested AMD PDUs. At least one requested AMD 
PDU is needed to activate the EPC mechanism. The variable VR(EP) is a counter, which is decremented every 
transmission time interval with the estimated number of AMD PDUs that should have been received during that 
transmission time interval on the corresponding logical channel. 

The timer Timer EPC controls the maximum time that the variable VR(EP) needs to wait before it will start counting 
down. This timer starts immediately after a transmission of a retransmission request from the Receiver (when the first 
STATUS PDU of the status report is submitted to lower layer (in UTRAN) or the successful or unsuccessful 
transmission of it is indicated by lower layer(in UE)). The initial value of the timer Timer_EPC is configured by upper 
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layers. It typically depends on the roundtrip delay, which consists of the propagation delay, processing time in the 
transmitter and Receiver and the frame structure. This timer can also be implemented as a counter, which counts the 
number of 10 ms radio frames that could be expected to elapse before the first requested AMD PDU is received. 

If not all of these requested AMD PDUs have been received correctly when VR(EP) is equal to zero, a new status report 
will be transmitted and the EPC mechanism will be reset accordingly. The timer Timer_EPC will be started once more 
when the first STATUS PDU of the status report is submitted to lower layer (in UTRAN) or the successful or 
unsuccessful transmission of it is indicated by lower layer (in UE). If all of the requested AMD PDUs have been 
received correctly, the EPC mechanism ends. 



9.7.5 Local Suspend function for acknowledged and unacknowledged 



The upper layers may suspend an RLC entity. 

When an RLC entity operating in unacknowledged mode is suspended by upper layers with the parameter N, the RLC 
entity shall: 

- acknowledge the suspend request with a confirmation containing the current value of VT(US); 

- not send UMD PDUs with sequence number SN>VT(US)+N. 

When an RLC entity operating in acknowledged mode is suspended by upper layers with the parameter N, the RLC 
entity shall: 

- acknowledge the suspend request with a confirmation containing the current value of VT(S); 

- not send AMD PDUs with sequence number SN>VT(S)+N. 

When an RLC entity operating in unacknowledged mode is resumed by upper layers, the RLC entity shall: 

resume data transfer procedure. 
When an RLC entity operating in acknowledged mode is resumed by upper layers, the RLC entity shall: 

- if the RLC entity is suspended and a RLC Reset procedure is not ongoing: 

- resume data transfer procedure. 

- otherwise, if the RLC entity is suspended and a RLC Reset procedure is ongoing: 

- remove the suspend constraint; 

- resume the RLC reset procedure according to subclause 1 1 .4. 



9.7.6 RLC Stop, RLC Continue function for acknowledged and 
unacknowledged mode 



The upper layer may stop an RLC entity. 

When an RLC entity is stopped, the RLC timers are not affected. 
When a RLC entity is stopped by upper layers, the RLC entity shall: 

- not submit any RLC PDUs to lower layer or receive any RLC PDUs; 

- delay triggered Polling functions or status transmissions until the RLC entity is continued. 
When a RLC entity is continued by upper layers, the RLC entity shall: 

- if the RLC entity is stopped: 

- continue the data transmission and reception; 

- process the triggered Polling functions and status transmissions. 



mode 
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- otherwise, if the RLC is not stopped: 

- take no action. 

9.7.7 RLC re-establishment function for acknowledged and 
unacknowledged mode 

The RLC re-establishment function is applicable for AM and UM and is used when upper layers request an RLC entity 
to be re-established. 

When an RLC entity is re-established by upper layers, the RLC entity shall: 

- reset the state variables to their initial value; 

- set the configurable parameters to their configured value; 

- set the hyper frame number (HFN) in UL and DL to the value configured by upper layers; 

- if the RLC entity is operating in unacknowledged mode: 

- if it is a receiving UM RLC entity: 

- discard all UMD PDUs; 

- if it is a transmitting UM RLC entity: 

- discard the RLC SDUs for which one or more segments have been submitted to a lower layer; 

- otherwise if the RLC entity is operating in acknowledged mode: 

- discard all AMD PDUs in the Receiver and Sender. 

9.7.8 Ciphering for acknowledged and unacknowledged mode 

The ciphering function is performed in RLC, according to the following rules if a radio bearer is using a non-transparent 
RLC mode (AM or UM). The data unit that is ciphered, depends on the transmission mode as described below. 

- For RLC UM mode, the ciphering unit is the UMD PDU excluding the first octet, i.e. excluding the RLC UMD 
PDU header. This is shown below in Figure 9.19. 
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Figure 9.19: Ciphering unit for a UMD PDU 



For RLC AM mode, the ciphering unit is the AMD PDU excluding the first two octets, i.e. excluding the RLC 
AMD PDU header. This is shown below in Figure 9.20. 
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Figure 9.20: Ciphering unit for an AMD PDU 

The ciphering algorithm and key to be used are configured by upper layers [8] and the ciphering method shall be 
applied as specified in [9]. ^ 

The parameters that are required by RLC for ciphering are defined in [9] and are input to the ciphering algorithm. The 
parameters required by RLC which are provided by upper layers [8] are listed below: 

- RLC AM HFN (Hyper frame number for radio bearers that are mapped onto RLC AM) 

- RLC UM HFN (Hyper frame number for radio bearers that are mapped onto RLC UM) 

- BEARER (Radio Bearer ID) 

- CK (Ciphering Key) 



10 Handling of unknown, unforeseen and erroneous 
protocol data 

Errors and the handling of errors defined in this clause are normative. 

10.1 Erroneous Sequence Number 

A STATUS PDU or Piggybacked STATUS PDU including "erroneous Sequence Number" is a STATUS PDU or 
Piggybacked STATUS PDU that contains: 

- a LIST, BITMAP or RLIST SUFI in which the "Sequence Number" of at least one PDU that is negatively 
acknowledged is outside the interval VT(A)<"Sequence Number"< VT(S)-1; or 

- an ACK SUFI in which "LSN" is outside the interval VT(A)<"LSN"< VT(S). 

If an AM RLC entity receives a STATUS PDU or a Piggybacked STATUS PDU including "erroneous Sequence 
Number", it shall: 

- discard the STATUS PDU or the Piggybacked STATUS PDU; 
initiate the RLC reset procedure (see subclause 1 1 .4). 

10.2 Inconsistent status indication 

If an AM RLC entity receives a STATUS PDU or a Piggybacked STATUS PDU that indicates different status for the 
same AMD PDU, it shall: 



3GPP 




Release 1 999 52 3GPP TS 25.322 V3.8.0 (2001 -09) 

- discard the STATUS PDU or the Piggybacked STATUS PDU. 

10.3 Invalid PDU format 

If an UM or AM RLC entity receives a RLC PDU that contains reserved or invalid values (see subclause 9.2), it shall: 

- discard the RLC PDU. 



1 1 Elementary procedures 

Procedures defined in this clause are normative. 

This description assumes elementary procedures. Interactions between procedures are not described. 

11.1 Transparent mode data transfer procedure 
11.1.1 General 

The transparent mode data transfer procedure is used for transferring data between two RLC peer entities, which are 
operating in transparent mode. Data is transferred from Sender to Receiver. This procedure should only apply to entities 
in DATA TRANSFER READY state. Figure 11.1 below illustrates the elementary procedure for transparent mode 
data transfer. 

Channels that can be used are DTCH, CCCH (uplink only), SHCCH (uplink only), BCCH and PCCH. The type of 
logical channel depends on if the RLC entity is located in the user plane (DTCH) or in the control plane 
(CCCH/BCCH/SHCCH/PCCH). 



Sender 




Receiver 




TMD PDU 


► 

















Figure 11.1: Transparent mode data transfer procedure 

11.1.2 Transmission of TMD PDU 

Upon a request of transparent mode data transfer from upper layer, the Sender shall: 

- if no SDU discard configuration has been made by upper layers: 

- discard SDUs received in previous TTIs;upon reception of new SDUs from upper layers (see subclause 
9.7.3.5); 

- otherwise (if "Timer Based SDU Discard without explicit signalling" is configured): 

- start a timer TimerDiscard for each SDU received from upper layers (see subclause 9.7.3); 

- schedule the RLC SDUs that have been received from upper layer for transmission; 

- if one or more RLC SDUs have been scheduled for transmission: 

- notify the lower layer of reception of data from upper layers; 

- perform the actions specified in subclause 11.1 .2.2. 
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11.1.2.1 TMD PDU contents to set 

The Sender shall set the data field of the TMD PDU to all or a subset of the data contained in the SDU as described in 
subclause 11.1 .2.2. 

11.1 .2.2 Submission of TMD PDUs to the lower layer 

If one or more RLC SDUs have been scheduled for transmission, according to Subclause 1 1.1.2, the Sender shall: 

- if it is configured for segmented operation: 

- inform the lower layer of the size of the next SDU to be sent; 

- segment the SDU according to the PDU size indicated by the lower layer. 

- otherwise (the Sender is configured for non-segmented operation): 

- inform the lower layer of the number and size of SDUs available for transmission; 

- submit to the lower layer, the requested number of TMD PDUs; 

- buffer the SDUs that are not submitted to the lower layer according to the discard configuration (see subclause 
9.7.3). 

11.1.3 Reception of TMD PDU 

Upon delivery by the lower layer of a set of TMD PDUs (received within one TTI), the Receiver shall: 

- if it is configured for segmented operation: 

- reassemble the TMD PDUs received in one TTI into one RLC SDU. 

- otherwise ( it is configured for non-segmented operation): 

- treat each received TMD PDU as a SDU; 

- if "Delivery of Erroneous SDUs" is configured as "no": 

- submit only the RLC SDUs received without error to upper layers through the TM-SAP. 

- else if "Delivery of Erroneous SDUs" is configured as "yes": 

- . submit all RLC SDUs to upper layers through the TM-SAP; 

- provide an error indication for each SDU received in error. 

- otherwise if "Delivery of Erroneous SDUs" is configured as "No detect": 

- submit all RLC SDUs to upper layers through the TM-SAP. 

If segmentation is performed in transparent mode RLC, an SDU is erroneous if one or more of the TMD PDUs received 
in a TTI contains an error. If segmentation is not performed, an SDU is erroneous if the corresponding TMD PDU is 
erroneous. 

1 1 ; 1 .4 Abnormal cases 

11.1.4.1 Void 

11.1.4.2 SDU discard without explicit signalling 

Upon expiry of the timer Timer_Discard in the Sender, the Sender shall: 
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- discard the associated SDU. 

In the case where the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the 
UE may wait until after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDU. 

1 1 .2 Unacknowledged mode data transfer procedure 
11.2.1 General 

The unacknowledged mode data transfer procedure is used for transferring data between two RLC peer entities, which 
are operating in unacknowledged mode. Data is transferred from Sender to Receiver. This procedure should only apply 
to RLC entities in D AT A TRAN S FER_RE AD Y state or LOCAL_SUSPEND state. Figure 1 1.2 below illustrates the 
elementary procedure for unacknowledged mode data transfer. 

Channels that can be used are DTCH, DCCH, CCCH (downlink only), CTCH, SHCCH (downlink only). The type of 
logical channel depends on if the RLC entity is located in the user plane (DTCH, CTCH) or in the control plane 
(DCCH/CCCH(downlink only)/SHCCH(downlink only)). One or several PDUs may be transmitted in each 
transmission time interval (TTI). For each TTI, MAC decides which PDU size shall be used and how many PDUs shall 
be transmitted. . 
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Figure 11.2: Unacknowledged mode data transfer procedure 



1 1 .2.2 Transmission of UMD PDU 

Upon a request of unacknowledged mode data transfer from upper layer, the Sender shall: 

- if no SDU discard configuration has been made by upper layers: 

- only discard SDUs when the Transmission buffer is full (see subclause 9.7.3); 

- if "Timer based SDU Discard without explicit signalling" is configured: 

- start a timer Timer Discard for each SDU received from upper layer (see subclause 9.7.3); 

- schedule the RLC SDUs received from upper layer for transmission; 

- if one or more RLC SDUs have been scheduled for transmission: 

- notify the lower layer of reception of data from upper layers; 

- perform the actions specified in subclause 1 1 .2.2.2. 

A UMD PDU shall be considered to be a padding PDU if it consists only of an RLC Header with one length indicator 
(indicating that the rest of the PDU is padding) and padding. 

1 1 .2.2.1 UMD PDU contents to set 

The Sender shall: 

- set the field "Sequence Number" equal to VT(US); 

- set a "Length Indicator" field for each SDU that ends in the UMD PDU according to subclause 9.2.2.8. 
For each "Extension bit" field in the RLC header, the Sender shall: 
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- if the next field in the UMD PDU is a "Length Indicator": 

- set the "Extension bit" to "1"; 

- otherwise if the next field in the UMD PDU is data: 

- set the "Extension bit" to "0". 

1 1 .2.2.2 Submission of UMD PDUs to the lower layer 

If one or more SDUs have been scheduled for transmission according to subclause 1 1 .2.2, the Sender shall: 

- inform the lower layer of the number and size of SDUs scheduled for transmission; 

- segment, and if possible concatenate the SDUs according to the PDU sizes indicated by the lower layer; 

- submit to the lower layer, the requested number of UMD PDUs; 

- update VT(US) for each UMD PDU submitted to the lower layer (see subclause 9.4); 

- buffer the SDUs that are not submitted to the lower layer according to the discard configuration (see subclause 



- if the updating step of VR(US) is not equal to one (i.e. one or more UMD PDUs are missing): 
- discard the SDUs that have segments in the missing UMD PDUs; 

- reassemble the received UMD PDUs into RJLC SDUs; 

- submit the RLC SDUs to upper layers through the UM-SAP. 

1 1 .2.4 Abnormal cases 

1 1 .2.4.1 Length Indicator value reserved for UMD PDU 

Upon delivery by the lower layer of an UMD PDU that contains a "Length Indicator" value specified to be reserved for 
UMD PDUs in this version of the protocol, the Receiver shall: 

- discard that UMD PDU and treat the UMD PDU as missing. 

1 1 .2.4.2 Invalid length indicator value 

If the "Length Indicator" of an UMD PDU has a value that is larger than the PDU size - RJLC header size and is.not one 
of the predefined values listed in the table of subclause 9.2.2.8, the Receiver shall: 

- discard the UMD PDU; and 

- treat the UMD PDU as missing. 

1 1 .2.4.3 SDU discard without explicit signalling 

Upon expiry of the timer Timer_Discard in the Sender, the Sender shall: 

- discard the associated SDU; 

- for the first UMD PDU to be transmitted after the discard operation, the Sender shall: 



9.7.3). 



1 1 .2.3 Reception of UMD PDU 

Upon delivery of a set of UMD PDUs from the lower layer, the Receiver shall: 
- update VR(US) according to each received UMD PDU (see subclause 9.4); 
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increment VT(US) so that the "Sequence Number" field in this UMD PDU is incremented with two 
compared with the previous UMD PDU; 

- fill the first data octet in this UMD PDU with the first octet of an RLC SDU; 

- set the first "Length Indicator" in this UMD PDU to indicate that the previous RLC PDU was exactly filled 
with the last segment of an RLC SDU (to avoid that the Receiver unnecessarily discards an extra SDU). 

In the case where the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the 
UE may wait until after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDU. 

11.3 Acknowledged mode data transfer procedure 
11.3.1 General 

The acknowledged mode data transfer procedure is used for transferring data between two RLC peer entities, which are 
operating in acknowledged mode. Data is transferred from Sender to Receiver. This procedure should only apply to 
RLC entities in DATA_TRANSFER_READY state or LOCAL_SUSPEND state. Figure 1 1.3 below illustrates the 
elementary procedure for acknowledge^ mode data transfer. 

The AMD PDUs shall be transmitted on the DCCH logical channel if the Sender is located in the control plane and on 
the DTCH if it is located jn the user plane. One or several PDUs may be transmitted in each transmission time interval 
(TTI) and MAC decides*how many PDUs shall be transmitted in each TTI. 
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Figure 11.3: Acknowledged mode data transfer procedure 



1 1 .3.2 Transmission of AMD PDU 

Upon a request of acknowledged mode data transfer from upper layers or upon retransmission of AMD PDUs, the 
Sender shall: 

- when RLC SDUs are received from upper layers: 

- segment the RLC SDUs into AMD PDUs where the fixed PDU size is configured by upper layer; 

- set a "Length Indicator" field for each SDU that ends in the AMD PDU according to subclause 9.2.2.8; 

- if "Timer based SDU Discard with explicit signalling" is configured: 

- start a timer Timer_Discard for each SDU received from upper layer (see subclause 9.7.3); 

- schedule the AMD PDUs for transmission; 

- if one or several AMD PDUs have been negatively acknowledged (see subclause 1 1 .5.3): 

- schedule the AMD PDUs that were negatively acknowledged for retransmission; 

- if a poll has been triggered by either the poll triggers "Poll timer" or "Timer based" (see subclause 9.7. l);and 

- if no AMD PDU is scheduled for transmission or retransmission: 

- if the value of "Configured_Tx_Window_Size" is larger than or equal to "2048": 

- select the AMD PDU with "Sequence Number" equal to VT(S)- 1 . 



3GPP 





Release 1999 



57 



3GPP TS 25.322 V3.8.0 (2001-09) 



otherwise if the "Configured_Tx_Window_Size" is less than "2048"; 

- select the AMD PDU with "Sequence Number" equal to VT(S)-1 ; or 

- select an AMD PDU that has not yet been acknowledged by the peer entity; 



schedule the selected AMD PDU for retransmission (in order to transmit a poll). 



The Sender may also schedule an AMD PDU for retransmission even if none of the criteria above is fulfilled. In this 
case, the Sender may: 

- if the value of "Configured_Tx_Window_Size" is larger than or equal to "2048": 

- select the AMD PDU with "Sequence Number" equal to VT(S)- 1 . 

- otherwise if the "Configured_Tx_Window_Size" is less than "2048": 

- select the AMD PDU with "Sequence Number" equal to VT(S)-1 ; or 

- select an AMD PDU that has not yet been acknowledged by the peer entity; 

- schedule the selected AMD PDlj for retransmission. 

Each time an AMD PDU is scheduled for transmission or retransmission, the Sender shall: 

- notify the lower layer that data is available for transmission; 

- perform the actions specified in subclause 1 1 .3.2.2. 

In AM, a PDU shall be considered to be a padding PDU if it is: 

- an AMD PDU consisting only of an RLC Header with one "Length Indicator" (indicating that the rest of the 
PDU is padding) and padding; or 

- a Status PDU consisting only of a NO_MORE SUFI. 

1 1 .3.2.1 AMD PDU contents to set 

If the AMD PDU is transmitted for the first time, the Sender shall: 

- set the "Sequence Number" field equal to VT(S); 

- set a "Length Indicator" field for each SDU that ends in the AMD PDU according to subclause 9.2.2.8. 

- otherwise if the AMD PDU is retransmitted: 

- use the same value of the "Sequence Number" field as in the original transmission of the AMD PDU; 

- if the "Length Indicator" fields needed in the AMD PDU according to subclause 9.2.2.8 has changed due to 
that a piggybacked STATUS PDU is included in the AMD PDU or a piggybacked STATUS PDU was 
included in the previous transmission of the AMD PDU: 

- update the "Length Indicator" fields according to 9.2.2.8. 

- set the "Polling bit" to the value specified in subclause 1 1 .3.2. 1 . 1 . 



11.3.2.1.1 



Setting of the Polling bit 



The Sender shall: 



- if a poll has been triggered by one or several poll triggers (see subclause 9.7. 1): 
- if polling is not prohibited, see subclause 9.5: 

- set the "Polling bit" in the AMD PDU header to " 1 "; 



- otherwise: 
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- set the "Polling bit" in the AMD PDU header to "0". 



11.3.2.1.2 



Void 



1 1 .3.2.2 Submission of AMD PDUs to lower layer 

If one or more AMD PDUs have been scheduled for transmission or retransmission according to Subclause 1 1 .3.2, the 
Sender shall: 

- not submit any AMD PDUs to lower layer that is not allowed to transmit. AMD PDUs are only allowed to 
transmit: 

- if the AMD PDU has a "Sequence Number" < VT(MS); or 

- if the AMD PDU has a "Sequence Number" equal to VT(S)-1 ; and 

- if the AMD PDU is not restricted to be transmitted by the local suspend function, see subclause 9.7.5. 

- inform the lower layer of the number of AMD PDUs scheduled for transmission or retransmission; 

- submit to the lower layer the requested number of AMD PDUs; 

- set the AMD PDU contents according to clause 1 1 .3.2. 1 ; 

- treat retransmissions with higher priority than AMD PDUs transmitted for the first time; 

- update the state variables in clause 9.4 for each AMD PDU submitted to lower layer; 

- if the "Polling bit" is set to "1 " in any of the AMD PDUs; and 
if the timer Timer_Poll is configured; 

- start the timer Timer_PolI according to subclause 9.5; 

- buffer the AMD PDUs that are not submitted to the lower layer according to the discard configuration (see 
subclause 9.7.3). 



Upon reception of an AMD PDU, the Receiver shall: 

- update VR(R), VR(H) and VR(MR) state variables for each received AMD PDU (see clause 9.4); 

- if a received AMD PDU includes a "Polling bit" set to "1", or "Missing PDU Indicator" is configured and the 
Receiver detects that a PDU is missing: 

- initiate the STATUS PDU transfer procedure; 

- reassemble the received AMD PDUs into RLC SDUs; 

- if "In-Sequence Delivery" is configured: 

- "submit the RLC SDUs in-sequence (i.e. in the same order as the RLC SDUs where originally transmitted by 
the peer entity) to upper layers through the AM-SAP. 

- otherwise if "In-Sequence Delivery" is not configured: 

- submit the RLC SDUs in arbitrary order to upper layers through the AM-SAP. 



1 1 .3.3 Reception of AMD PDU by the Receiver 
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11.3.4 Abnormal cases 

1 1 .3.4. 1 Timer_Poll timeout 

Upon expiry of the timer Timer_Poll, the Sender shall: 

- if an AMD PDU is available for transmission: 

- transmit an AMD PDU with the "Polling bit" set to "1"; 

- otherwise if no AMD PDU is available for transmission: 

- retransmit an AMD PDU even if that AMD PDU is not negatively acknowledged, with the "Polling bit" set 
to"l"; 

- initiate the acknowledged mode data transfer procedure for the AMD PDU to be transmitted or retransmitted. 

1 1 .3.4.2 Receiving an AMD PDU outside the receiving window 

Upon reception of an AMD PDU with sequence number outside the interval VR(R)<SN<VR(MR), the Receiver shall: 

- discard the AMD PDU; 

- if the "polling bit" in the discarded AMD PDU is set to " 1 ": 

- initiate the STATUS PDU transfer procedure. 

1 1 .3.4.3 Timer_Discard timeout 

1 1 .3.4.3. 1 SDU discard with explicit signalling 

Upon expiry of the timer Timer Discard, the Sender shall: 

- initiate the SDU discard with explicit signalling procedure, see subclause 1 1 .6.2. 

In the case where the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the 
UE may wait until after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDUs. 

1 1 .3.4.4 VT(DAT) > MaxDAT 

The Sender shall: 

- if VT(DAT) > MaxDAT for any AMD PDU: 

- if "No_discard after MaxDAT number of transmissions" is configured: 

- initiate the RLC reset procedure, see subclause 1 1 .4; 

- if "SDU discard after MaxDAT number of transmissions" is configured: 

- initiate the "SDU discard with explicit signalling" procedure, see subclause 1 1 .6. 

1 1 .3.4.5 Invalid length indicator value 

If the "Length Indicator" of an AMD PDU has a value that is larger than the PDU size - RLC header size and is not one 
of the predefined values listed in the table of subclause 9.2.2.8, the Sender shall: 

- discard that AMD PDU; and 

- treat the discarded AMD PDU as missing. 
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1 1 .3.4.6 Length Indicator value reserved for AMD PDU 

Upon de livery by the lower layer of an AMD PDU that contains a "Length Indicator" value specified to be reserved for 
AMD PDUs in this version of the protocol, the Receiver shall: 

- discard that AMD PDU; 

- treat the discarded AMD PDU as missing. 

1 1 .3.4.7 VT(DAT) > MaxDAT-1 

The Sender shall not perform the transmission of the PDU. Instead, it will only increment the corresponding VT(DAT). 

1 1 .4 RLC reset procedure 
11.4.1 General 

The RLC reset procedure is used to reset two RLC peer entities, which are operating in acknowledged mode. 
Figure 1 1 .4 below illustrates the elemeritary procedure for an RLC reset. During the reset procedure the hyper frame 
numbers (HFN) in UTRAN and UE are synchronised. Two HFNs used for ciphering needs to be synchronised, DL 
HFN in downlink and UL HFN in uplink. In the reset procedure, the highest UL HFN and DL HFN used by the RLC 
entity in the transmitting sides, i.e. the HFNs associated with PDUs of SN=VT(S>1 if at least one data PDU had been 
transmitted or of SN=0 if no data PDU had been transmitted, are exchanged between UE and UTRAN. 

The RESET PDUs and the RESET ACK PDUs have higher priority than AMD PDUs. 
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Figure 11.4: RLC reset procedure 



11.4.2 Initiation 

The Sender shall: 

- if one of the following triggers is detected: 

1 ) "No_Discard after MaxDAT number of retransmissions" is configured and VT(DAT) equals the value MaxDAT 
(see subclause 9.7.3.4); 

2) VT(MRW) equals the value MaxMRW; 

3) A STATUS PDU including "erroneous Sequence Number" is received (see clause 10); 

- submit a RESET PDU to the lower layer; 

- start the timer Timer_RST and increase VT(RST) with 1 . 

When a reset procedure has been initiated it can only be ended upon reception of a RESET ACK PDU with the same 
RSN value as in the corresponding RESET PDU, or upon request of re-establishment or release from upper layer, a 
reset procedure is not interrupted by the reception of a RESET PDU from the peer entity. 
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1 1 .4.2.1 RESET PDU contents to set 

The Sender shall: 

- set the HFNI field to the currently highest used HFN (DL HFN when the RESET PDU is sent by UTRAN or UL 
HFN when the RESET PDU is sent by the UE); 

- set the RSN field to the sequence number of the RESET PDU. This sequence number is incremented every time 
a new RESET PDU is transmitted, but not when a RESET PDU is retransmitted. 

1 1 .4.3 Reception of the RESET PDU by the Receiver 

Upon reception of a RESET PDU the Receiver shall: 

- submit a RESET ACK PDU to the lower layer; 

- reset the state variables described in subclause 9.4 except VT(RST) to their initial values; 

- stop all the timers described in subclause 9.5 except Timer_RST; 

- reset configurable parameters to their configured values; 

- discard all RLC PDUs in the receiving side of the AM RLC entity; 

- discard all RLC SDUs that were transmitted before the reset in the transmitting side of the AM RLC entity; 

- set the HFN (DL HFN when the RESET PDU is received in UE or UL HFN when the RESET PDU is received 
in UTRAN) equal to the HFNI field in the received RESET PDU; 

- increase with one the UL HFN and DL HFN, and the updated HFN values shall be used for the first transmitted 
and received PDUs after the reset procedure. 

1 1 .4.3.1 RESET ACK PDU contents to set 

The Receiver shall: 

- set the hyper frame number indicator field (HFNI) to the currently highest used HFN (DL HFN when the RESET 
ACK PDU is sent by UTRAN or UL HFN when the RESET ACK PDU is sent by the UE); 

- set the RSN field to the same value as in the corresponding received RESET PDU. 

1 1 .4.4 Reception of the RESET ACK PDU by the Sender 

Upon reception of a RESET ACK PDU, the Sender shall: 

- if the Sender has already transmitted a RESET PDU which has not been yet acknowledged by a RESET ACK 
PDU: 

- if the received RSN value is the same as the one in the corresponding RESET PDU: 

- set the HFN value (DL HFN when the RESET ACK PDU is received in UE or UL HFN when the RESET 
ACK PDU is received in UTRAN) to the HFNI field of the received RESET ACK PDU; 

- reset the state variables described in subclause 9.4 to their initial values; 

- stop all the timers described in subclause 9.5; 

- reset configurable parameters to their configured values; 

- discard all RLC PDUs in the receiving side of the AM RLC entity; 

- discard all RLC SDUs that were transmitted before the reset in the transmitting side of the AM RLC 
entity; 
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- increase with one the UL HFN and DL HFN, and the updated HFN values shall be used for the first 
transmitted and received PDUs after the reset procedure; 

- otherwise (if the received RSN value is not the same as the one in the corresponding RESET PDU): 

- discard the RESET ACK PDU; 

- otherwise (if the Sender has not transmitted a RESET PDU which has not been yet acknowledged by a RESET 
ACK PDU): 

- discard the RESET ACK PDU. 

1 1 .4.5 Abnormal cases 

1 1 .4.5.1 TimerJRST timeout 

If Timer_RST expires before the reset procedure is terminated, the Sender shall: 

- ifVT(RST)<MaxRST-l: 

- set the RESET PDU as previously transmitted (even if additional SDUs were discarded in the mean-time); 

- transmit RESET PDU; 

- increment VT(RST) by one; 

- restart Timer_RST. 

1 1 .4.5.2 Unrecoverable error (VT(RST) > MaxRST) 

The Sender shall: 

- if VT(RST) becomes larger than or equal to MaxRST: 

indicate unrecoverable error to upper layer. 

1 1 .4.5.3 Reception of the RESET PDU by the Sender 

Upon reception of a RESET PDU, the Sender shall: 

- submit a RESET ACK PDU to the lower layer; 

- reset the state variables described in subclause 9.4 except VT(RST) to their initial values; 

- stop all the timers described in subclause 9.5 except Timer_RST; 

- reset configurable parameters to their configured values; 

- discard all RLC PDUs in the receiving side of the AM RLC entity; 

- discard all RLC SDUs that were transmitted before the reset in the transmitting side of the AM RLC entity; 

- set the HFN (DL HFN when the RESET PDU is received in UE or UL HFN when the RESET PDU is received 
in UTRAN) equal to the HFNI field in the received RESET PDU; 

- increase with one the UL HFN and DL HFN, and the updated HFN values shall be used for the first transmitted 
and received PDUs after the reset procedure. 
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1 1 .5 STATUS report transfer procedure 
11.5.1 General 

The status report transfer procedure is used for transferring of status information between two RLC peer entities, which 
are operating in acknowledged mode. Figure 1 1.5 below illustrates the elementary procedure for status report transfer. 
A status report consists of one or several STATUS PDUs. 

In case two logical channels are configured in the uplink, control PDUs are transmitted on the second logical channel. 
In case two logical channels are configured in the downlink, control PDUs can be transmitted on any of the two logical 
channels. 

The STATUS PDUs have higher priority than AMD PDUs. 



Sender 


Receiver 




STATUS PDU 






m 

■<m - . . / 





Figure 11.5: Status report transfer procedure 



11.5.2 Initiation 

The Receiver shall: 

- if one of the following triggers is detected: 

1 ) The "Polling bit" in a received AMD PDU is set to "1"; 

2) "Missing PDU Indicator" is configured and a missing AMD PDU is detected; 

3) The "Timer based STATUS transfer" is configured and the timer Timer_Status_Periodic has expired: 

- act on the trigger as specified in subclause 9.7.2. 

1 1 .5.2.1 Piggybacked STATUS PDU 

The Receiver may: 

- if STATUS PDU(s) to be sent fit into padding octets in AMD PDU(s) to be sent: 

- piggyback a STATUS PDU on the AMD PDU to be sent. 

Submission of a piggybacked STATUS PDU in an AMD PDU to the lower layer follows the same rules as an ordinary 
STATUS PDU. 

1 1 .5.2.2 STATUS PDU contents to set 

On triggering of a status report, the Receiver shall: 

- if neither the "STATUS prohibit" nor "EPC mechanism" are active: 

- include negative acknowledgements for all AMD PDUs detected as missing; 

- include acknowledgements for all AMD PDUs received up to at least VR(R); 

- if "SDU discard with explicit signalling" procedure has been initiated since the last status report was sent: 

- optionally include one MRW SUFI as specified in subclause 1 1.6.2.2; 
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if the MRW SUFI was received in the last status report received: 

- include one MRW_ACK SUFI as specified in subclause 1 1. 6.3.2; 

- if the Sender's transmission window is to be updated: 

- include the WINDOW SUFI; 

if all SUFIs can be accommodated in one STATUS PDU: 

- construct the status report using one STATUS PDU, using one of the allowed PDU sizes; 

- if the SUFIs included do not fill the entire STATUS PDU: 

- terminate the STATUS PDU with the ACK or NO_MORE SUFI; 

- use padding in the remainder of the STATUS PDU; 

- otherwise (SUFIs included fill the entire STATUS PDU): 

- ACK or NO_MORE SUFIs need not be included in that STATUS PDU; 

- otherwise (the status report is segmented): 

- construct STATUS PDUs including only complete SUFIs using one of the allowed PDU sizes. The set of 
STATUS PDUs shall accommodate all the SUFIs to form the complete status report. Indication of the same 
AMD PDU shall not be given in more than one STATUS PDU of a status report, but the ACK SUFI can be 
present in more than one STATUS PDU of a status report; 

- if any STATUS PDU constructed is not entirely filled with SUFIs: 

- terminate that STATUS PDU with the ACK or NO_MORE SUFI; 

- use padding in the remainder of that STATUS PDU. 

- otherwise (SUFIs included fill the entire STATUS PDU): 

- ACK or NOJvtORE SUFIs should not be included in that STATUS PDU. 

Which SUFI fields to use is implementation dependent. Bitmap SUFI is used to indicate both received and/or missing 
AMD PDUs. List SUFI and/or Relative List SUFI are used to indicate missing AMD PDUs only. Acknowledgement 
SUFI is used to indicate the received AMD PDUs. (For SUFI details see 9.2.2.1 1.) No information shall be given for 
AMD PDUs with SN>VR(H), i.e. AMD PDUs that have not yet reached the Receiver. 

1 1 .5.2.3 Submission of STATUS PDUs to the lower layer 

The Receiver shall: 

- inform the lower layer of the STATUS PDUs scheduled for transmission; 

- submit to the lower layer, the requested number of PDUs (STATUS PDUs, piggybacked AMD / STATUS PDUs 
and optionally AMD PDUs, see also subclause 1 1.3.2.2); 

- if "Timer based STATUS transfer" is configured and the timer Timer_Status_Periodic has expired: 

- "restart the timer Timer_Status_Periodic according to subclause 9.5 f); 

- if the "EPC mechanism" is configured: 

- start the timer TimerJZPC according to subclause 9.5 c), and set VR(EP) equal to the number of AMD PDUs 
requested to be retransmitted; 

- if the STATUS PDU includes the MRW SUFI: 

- start the timer Timer MRW according to subclause 9.5 i). 
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1 1 .5.3 Reception of the STATUS PDU by the Sender 

Upon reception of the STATUS PDU/piggybacked STATUS PDU, the Sender shall: 

- update the state variables VT(A) and VT(MS) according to the received STATUS PDU/piggybacked STATUS 
PDU; 

- if the STATUS PDU includes negatively acknowledged AMD PDUs: 

- initiate the acknowledged data transfer procedure; and 

- retransmit these AMD PDUs. Retransmitted AMD PDUs shall have higher priority than AMD PDUs to be 
transmitted for the first time; 

- if an AMD PDU is negatively acknowledged more than once in a STATUS PDU: 
- retransmit the AMD PDU only once; 

- if the STATUS PDU includes the MRW SUFI: 

- take the actions specified in subclause 1 1 .6.3; 

- if the STATUS PDU includes the MRW ACK SUFI: 

- take the actions specified in subclause 1 1 .6.4; 

- if the STATUS PDU includes the WINDOW SUFI: 

- update the current transmitter window size, VT(WS). 

1 1 .5.4 Abnormal cases 

1 1.5.4.1 VR(EP) equals zero and the requested AMD PDUs have not been received 

If the EPC mechanism is configured and VR(EP) equals zero and not all AMD PDUs requested for retransmission have 
been received, the Receiver shall: 

- retransmit the status report. The retransmitted status report may contain new or different SUFI fields in order to 
indicate that some previously lost AMD PDUs have been received and that some additional AMD PDUs have 
been lost. 



The SDU discard with explicit signalling procedure is used for discarding SDUs and transferring the discard 
information between two peer entities, which are operating in acknowledged mode. The Sender shall discard an SDU 
that has not been successfully transmitted for a period of time or for a number of transmissions, and send a Move 
Receiving Window (MRW) SUFI to the Receiver. According to the MRW SUFI, the Receiver shall discard AMD 
PDUs carrying that SDU and update the receiving window. Figure 1 1 .6 below illustrates the elementary procedure for 
SDU discard with explicit signalling. 
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.6 SDU discard with explicit signalling procedure 
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^ STATUS PDU (MRW ACK SUFI) 










! 







Figure 11.6: SDU discard with explicit signalling 



11.6.2 Initiation 

The Sender shall initiate the SDU discard with explicit signalling procedure if one of the following triggers is detected: 

"Timer based SDU discard with explicit signalling" is configured, Timer_Discard expires for an SDU, and one 
or more segments of the SDU have been submitted to a lower layer; 

- "Timer based SDU discard with Explicit signalling" is configured, Timer_Discard expires for an SDU, and Send 
MRW is configured; 

- "SDU discard after MaxDAT number of transmissions" is configured, and MaxDAT number of transmissions is 
reached (i.e. VT(DAT) > MaxDAT) for an AMD PDU. 

Upon initiation of the SDU discard with explicit signalling procedure, the Sender shall: 

- if "Timer based SDU discard with explicit signalling" is configured: 

- discard all SDUs up to and including the SDU for which the timer Timer_Discard expired; 

- not discard AMD PDUs carrying segments of other SDUs whose timers have not expired; 

- if "SDU discard after MaxDAT number of retransmissions" is configured: 

- discard all SDUs that have segments in AMD PDUs with SN inside the interval VT(A) < SN < X, where X is 
the value of the SN of the AMD PDU with VT(DAT) > MaxDAT; 

- if more than 15 discarded SDUs are to be informed to the Receiver: 

- assemble an MRW SUFI with the discard information of the first 15 SDUs. The discard information of the 
rest SDUs shall be included in another MRW SUFI which shall be sent by the next SDU discard with explicit 
signalling procedure (after the current SDU discard with explicit signalling procedure is terminated); 

- otherwise (less than or equal to 15 discarded SDUs are to be informed to the Receiver): 

- assemble an MRW SUFI with the discard information of the SDUs; 

- . include the MRW SUFI in the next STATUS PDU/piggybacked STATUS PDU to be transmitted, according to 

subclause 1 1.5.2; 

- if SN_MRW L ength in the MRW SUFI > VT(S): 

- "update VT(S) to SN_MRW LENGT h; 

- start a timer Timer_MRW according to subclause 9.5. 

If a new SDU discard with explicit signalling procedure is triggered when the timer Timer_MRW is active, no new 
MRW SUFIs shall be sent before the current SDU discard with explicit signalling procedure is terminated by one of the 
termination criteria specified in subclause 1 1.6.4. 

11.6.2.1 Void 
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| 1 1 .6.2.2 STATUS PDU contents to set 

; The Sender shall: 

- if "Send MRW" is configured: 

- if the last discarded SDU ended in an AMD PDU, and its LI is present in the same AMD PDU, and no new 
SDU is present inside this AMD PDU: 

- set the last SN_MRW f field in the MRW SUFI to 1 + SN of the AMD PDU which contains the LI of the 
last discarded SDU; 

- set the N LENG th field in the MRW SUFI to "0000". 

- otherwise: 

- set the last SNMRWj field in the MRW SUFI to the SN of the AMD PDU which contains the LI of the 
last discarded SDU; 

- set the Nlength field in the MRW SUFI so that the last data octet to be discarded in the Receiver shall be 
the octet indicated by the Nlength -th LI field of the AMD PDU which contains the LI of the last 
discarded SDU; * 

I 

- set each of the other SN_MRW; fields in the MRW SUFI to the SN of the AMD PDU which contains the LI 
of the i:th discarded SDU. 

- otherwise ("Send MRW" is not configured): 

- if the last SDU to be discarded in the Receiver ended in an AMD PDU, and its LI is present in the same 
AMD PDU, and no new SDU is present inside this AMD PDU: 

- set the last SN_MRW; field in the MRW SUFI to 1 + SN of the AMD PDU which contains the LI of the 
last SDU to be discarded in the Receiver; 

- set the Nlength field in the MRW SUFI to "0000". 
otherwise: 

- set the last SNJvlRWj field in the MRW SUFI to the SN of the AMD PDU which contains the LI of the 
last SDU to be discarded in the Receiver; 

- set the Nlength field in the MRW SUFI so that the last data octet to be discarded in the Receiver shall be 
the octet indicated by the Nlength -th LI field of the AMD PDU which contains the LI of the last SDU to 
be discarded in the Receiver; - 

- optionally set each of the other SNJvlRWj fields in the MRW SUFI to the SN of the AMD PDU which 
contains the LI of the i:th SDU to be discarded in the Receiver; 

- if the MRW SUFI contains only one SN_MRW* field and the value of SN_MRW; field > 
VT(A)+Configured_Tx_Window_Si2e: 

- set the LENGTH field in the MRW SUFI to "0000". 

- otherwise: 

- 'set the LENGTH field in the MRW SUFI to the number of SN_MRW ; fields in the same MRW SUFI. In this 

case, SN_MRW, shall be in the interval VT(A) < SN_MRW, < VT(A)+Configured_Tx_Window_Size; , 

- include the MRW SUFI in the next STATUS PDU/piggybacked STATUS PDU to be transmitted, according to 
subclause 1 1.5.2. 

1 1 .6.3 Reception of the STATUS PDU by the Receiver 

Upon reception of the STATUS PDU/piggybacked STATUS PDU containing an MRW SUFI, the Receiver shall: 

- if the LENGTH field in the received MRW SUFI is "0000": 
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- consider SN_MRW, to be above or equal to VR(R). 

- otherwise: 

- consider SNJvtRW, to be less than VR(MR); 

- consider all the SNMRWjs other than SN_MRWi to be in sequential order within the list and sequentially 
above or equal to SN_MRWj_,. 

- discard AMD PDUs up to and including the PDU with sequence number SN_MRWlength-1 ; 

- if the N LENGTH field in the received MRW SUFI is "0000": 

- reassemble from the first data octet of the AMD PDU with sequence number SN_MRW LENG th after the 
discard. 

- otherwise: 

- discard further the data octets in the AMD PDU with sequence number SN_MRW LENGTH up to and including 
the octet indicated by the N length "th LI field of the PDU with sequence number SN_MRW LENGTH ; 

- reassemble from the succeeding data octet in the AMD PDU with sequence number SN_MRW LENG th after 
the discard; 

- if "Send MRW" is configured: 

- inform upper layers about all of the discarded SDUs that were not previously delivered to upper layer or 
discarded by other MRW SUFIs; 

- update the state variables VR(R), VR(H) and VR(MR) according to the received STATUS PDU/piggybacked 
STATUS PDU; 

- include an MRW ACK SUFI in the next STATUS PDU/piggybacked STATUS PDU to be transmitted, 
according to subclause 1 1.5.2; 

1 1 .6.3.1 STATUS PDU contents to set 

The Receiver shall: 

- set the SN_ACK field in the MRW_ACK SUFI to the new value of VR(R), updated after reception of the MRW 
SUFI; 

- if the SN_ACK field in the MRWACK SUFI is set equal to the SN_MRW LE ngth field in the received MRW 
SUFI: - 

- set the N field in the MRW ACK SUFI to the N length field in the received MRW SUFI, 
otherwise: 

- set the N field in the MRW_ACK SUFI to "0000"; 

- include the MRW ACK SUFI in the next STATUS PDU/piggybacked STATUS PDU to be transmitted, 
according to subclause 1 1 .5.2. 

11.6.4' Termination 

The Sender shall terminate the SDU discard with explicit signalling procedure if one of the following criteria is fulfilled: 

- a STATUS PDU/piggybacked STATUS PDU containing an MRW ACK SUFI is received, and the SN_ACK 
field in the received MRW_ACK SUFI > the SN_MRW LENGT h field in the transmitted MRW_SUFI, and the N 
field in the received MRW_ACK SUFI is set equal to "0000"; 

- a STATUS PDU/piggybacked STATUS PDU containing an MRW_ACK SUFI is received, and the SN_ACK 
field in the received MRW ACK SUFI = the SN_M R W length field in the transmitted MRW_SUFI, and the N 
field in the received MRW ACK SUFI is set equal to the N length field in the transmitted MRW SUFI; 
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- a STATUS PDU/piggybacked STATUS PDU containing an ACK SUFI is received, and the LSN field in the 
received ACK SUFI > the SNJvIRWlengjh field in the transmitted MRW SUFI. 

Upon termination of the SDU discard with explicit signalling procedure, the Sender shall: 

- stop the timer Timer_MRW; 

- update VT(A) and VT(MS) according to the received STATUS PDU/piggybacked STATUS PDU; 
The Sender shall not confirm to upper layers the SDUs that are requested to be discarded. 

1 1 .6.5 Expiration of timer Timer_MRW 

If TimerMRW expires before the discard procedure is terminated, the Sender shall: 

- if VT(MRW)<MaxMRW-l : 

- set the MRW SUFI as previously transmitted (even if additional SDUs were discarded in the mean-time); 

- include the MRW SUFI in a new status report (if other SUFIs are included, their contents shall be updated); 

- transmit the status report by either including it in a STATUS PDU or piggybacked in an AMD PDU; 

- increment VT(MRW) by one; 

- restart Timer MRW for this discard procedure. 

11.6.6 Abnormal cases 

1 1 .6.6.1 Reception of obsolete/corrupted MRW SUFI by the Receiver 

If the received MRW SUFI contains outdated information about the receiving window (receiving window already' 
moved further than MRW SUFI is indicating), the Receiver shall: 

- discard the MRW SUFI; 

- set the SN_ACK field in the MRWACK SUFI to the current value of VR(R); 

- set the N field in the MRW_ACK SUFI to "0000"; 

- include the MRW_ACK SUFI in the next STATUS PDU/piggybacked STATUS PDU to be transmitted, 
according to subclause 1 1 .5.2. 

1 1 .6.6.2 VT(MRW) equals MaxMRW 

If the number of retransmission of an MRW SUFI (i.e. VT(MRW)) equals MaxMRW, the Sender shall: 

- terminate the SDU discard with explicit signalling procedure; 

- stop the timer Timer_MRW; 

- deliver an error indication to upper layers; 

- initiate the RLC RESET procedure (see clause 1 1 .4). 

1 1 .6.6.3 Reception of obsolete/corrupted MRW_ACK SUFI by the Sender 

The Sender shall discard the received MRW_ACK SUFI if one of the following cases occurs: 

- the timer Timer_MRW is not active; or 

- the SN_ACK field in the received MRW ACK SUFI < the SN_MRW LE ngth field in the transmitted MRW SUFI; 
or 
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- the SN_ACK field in the received MRW_ACK SUFI = the SNMRWlencto field in the transmitted MRW SUFI, 
and the N field in the received MRWACK SUFI is not equal to the Nlength field in the transmitted MRW SUFI; 
or 

- the SN_ACK field in the received MRW ACK SUFI > the SN.MRWlencth field in the transmitted MRW SUFI, 
and the N field in the received MRW ACK SUFI is not equal to "0000". 
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